Attachment 159104 Details for Bug 201780 – security/vuxml for libidn out-of-bounds read issue with invalid UTF-8 input

[patch] security/vuxml for libidn out-of-bounds read issue with invalid UTF-8 input

libidn_vuxml.patch (text/plain), 2.93 KB, created by Jason Unovitch on 2015-07-23 03:30:39 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jason Unovitch

Created: 2015-07-23 03:30:39 UTC

Size: 2.93 KB

patch

obsolete

>Index: vuln.xml
>===================================================================
>--- vuln.xml	(revision 392703)
>+++ vuln.xml	(working copy)
>@@ -58,6 +58,57 @@
> 
> -->
> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
>+  <vuln vid="4caf01e2-30e6-11e5-a4a5-002590263bf5">
>+    <topic>libidn -- out-of-bounds read issue with invalid UTF-8 input</topic>
>+    <affects>
>+      <package>
>+	<name>libidn</name>
>+	<range><lt>1.3.1</lt></range>
>+      </package>
>+    </affects>
>+    <description>
>+      <body xmlns="http://www.w3.org/1999/xhtml">
>+	<p>Simon Josefsson reports:</p>
>+	<blockquote cite="http://git.savannah.gnu.org/cgit/libidn.git/plain/NEWS?id=libidn-1-31">
>+	  <p>stringprep_utf8_to_ucs4 now rejects invalid UTF-8. 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.</p>
>+	</blockquote>
>+      </body>
>+    </description>
>+    <references>
>+      <cvename>CVE-2015-2059</cvename>
>+      <url>http://git.savannah.gnu.org/cgit/libidn.git/plain/NEWS?id=libidn-1-31</url>
>+    </references>
>+    <dates>
>+      <discovery>2015-02-09</discovery>
>+      <entry>2015-07-23</entry>
>+    </dates>
>+  </vuln>
>+
>   <vuln vid="95eee71d-3068-11e5-a9b5-bcaec565249c">
>     <topic>gdk-pixbuf2 -- heap overflow and DoS affecting Firefox and other programs</topic>
>     <affects>

Flags:

junovitch: maintainer-approval? (ports-secteam)

Actions: View | Diff

Attachments on bug 201780: 159103 | 159104 | 159105