Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 541970 (CVE-2015-2059) - <net-dns/libidn-1.33: out-of-bounds read with stringprep on invalid UTF-8 (CVE-2015-2059)
Summary: <net-dns/libidn-1.33: out-of-bounds read with stringprep on invalid UTF-8 (CV...
Status: RESOLVED FIXED
Alias: CVE-2015-2059
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: B3 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-03 08:32 UTC by Agostino Sarubbo
Modified: 2016-11-22 13:20 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-03-03 08:32:33 UTC
From ${URL} :

An out-of-bounds read flaw was found in libidn, which could potentially allow an attacker to disclose sensitive information from an application using the libidn library.

This flaw was identified along with a flaw in jabberd2 (CVE-2015-2058, bug 1191149). MITRE assigned a separate CVE for libidn with the following reasoning:

"""
> The libidn documentation claims "This function will not read or write to
> characters outside that size." about the length of the buffer that needs to
> be specified, but this is not true,

Use CVE-2015-2059 for this libidn out-of-bounds read issue. Possibly
it could be argued that this is a borderline case for a CVE. However,
the documentation says "This function will not read or write to
characters outside that size" rather than "If the input is valid
UTF-8, then this function will not read or write to characters outside
that size." If the input is not valid UTF-8, then the function is
entitled to undefined behavior within the bounds of the buffer.
"""
[http://seclists.org/oss-sec/2015/q1/672]

Related upstream issue:

https://github.com/jabberd2/jabberd2/issues/85


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Agostino Sarubbo gentoo-dev 2015-03-30 10:34:54 UTC
*** Bug 545048 has been marked as a duplicate of this bug. ***
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2015-03-30 16:27:59 UTC
1.30 has been in the tree for nearly a month now, but I have yet to see confirmation that this version has any of the fixes mentioned on the Internets.
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2015-05-18 04:45:28 UTC
Debian (https://security-tracker.debian.org/tracker/CVE-2015-2059) says:
 "Mis-use of an API (even if poorly documented) is hardly a security issue"
Comment 4 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-07-08 15:58:37 UTC
upstream commit:

http://git.savannah.gnu.org/cgit/libidn.git/commit/?id=2e97c279
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2015-07-09 07:08:28 UTC
1.31 is in the tree, but it doesn't directly fix this vulnerability. They just changed the code so it fails more readily when an invalid UTF-8 string is passed to catch out bad API usage. To quote NEWS:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* Version 1.31 (released 2015-07-08) [beta]
 
** libidn: stringprep_utf8_to_ucs4 now rejects invalid UTF-8. CVE-2015-2059
This function has always been documented to not validate that the
input UTF-8 string is actually valid UTF-8.  Like the rest of the API,
when you call a function that works on UTF-8 data, you have to pass it
valid UTF-8 data.  Application writers appear to have difficulties
using interfaces designed like that, as bugs triggered by invalid
UTF-8 has been identified in a number of projects (jabberd2, gnutls,
wget, and curl).  While we could introduce a new API to perform UTF-8
validation, so that applications can easily implement the proper
checks, this appear error prone because there is a risk that the check
will be forgotten.  Instead, we took the more radical approach of
modifying the documentation and the implementation of the API.  The
intention is that all functions that accepts UTF-8 data should
validate it before use.  This will solve the problem for applications,
without needing to change them.  This change has the unfortunate
side-effect that Surrogate codes (see section 5.5 of RFC 3454) no
longer trigger the STRINGPREP_CONTAINS_PROHIBITED error code but
instead will trigger the newly introduced STRINGPREP_ICONV_ERROR error
code, as the gnulib/libunistring-based code that we use to test
UTF-8-compliance rejects Surrogate codes.  We hope that this is an
acceptable cost to live with in order to improve application security.
We welcome feedback on this solution, and we are marking this release
as beta rather than stable to signal that we may reconsider this
approach if people disagree.  Reported by several people including
Thijs Alkemade, Gustavo Grieco, Daniel Stenberg, and Nikos
Mavrogiannopoulos.
 
** libidn: Added STRINGPREP_ICONV_ERROR error code.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

So we could stabilise 1.31 but that wouldn't fix older releases of the applications written without UTF-8 validation before strings are passed on to libidn.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2015-07-09 07:08:57 UTC
Oh, and 1.31 is considered a beta. So it probably shouldn't go stable to begin with.
Comment 7 James Le Cuirot gentoo-dev 2016-01-02 16:54:45 UTC
According to NEWS, this has been fixed in the unreleased 1.33 but that is also a beta. I wanted 1.32 to go stable for an unrelated reason but I guess I'll have to make do with masking the doc flag for 1.30. It doesn't actually work in that version anyway.
Comment 8 Thomas Deutschmann gentoo-dev Security 2016-11-22 13:08:49 UTC
OK, v1.33 is in the repository and went stable in the meanwhile.


@ Security: Please vote!
Comment 9 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-11-22 13:20:07 UTC
As reported by upstream news (and noted by chewi) the crash has been fixed:

** libidn: stringprep_utf8_nfkc_normalize reject invalid UTF-8.
It was always documented to only accept UTF-8 data, but now it doesn't
crash when presented with such data.  Reported by Hanno Böck.

Tree is clean.

GLSA Vote: No