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.
*** Bug 545048 has been marked as a duplicate of this bug. ***
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.
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"
upstream commit: http://git.savannah.gnu.org/cgit/libidn.git/commit/?id=2e97c279
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.
Oh, and 1.31 is considered a beta. So it probably shouldn't go stable to begin with.
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.
OK, v1.33 is in the repository and went stable in the meanwhile. @ Security: Please vote!
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
