svn commit: r447592 - head/security/vuxml

Wed Aug 9 07:18:43 UTC 2017

Author: brnrd
Date: Wed Aug  9 07:18:42 2017
New Revision: 447592
URL: https://svnweb.freebsd.org/changeset/ports/447592

Log:
  security/vuxml: Document today's cURL vulnerabilities

Modified:
  head/security/vuxml/vuln.xml

Modified: head/security/vuxml/vuln.xml
==============================================================================

--- head/security/vuxml/vuln.xml	Wed Aug  9 06:30:49 2017	(r447591)
+++ head/security/vuxml/vuln.xml	Wed Aug  9 07:18:42 2017	(r447592)
@@ -58,6 +58,76 @@ Notes:
   * Do not forget port variants (linux-f10-libxml2, libxml2, etc.)
 -->
 <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
+  <vuln vid="69cfa386-7cd0-11e7-867f-b499baebfeaf">
+    <topic>cURL -- multiple vulnerabilities</topic>
+    <affects>
+      <package>
+	<name>curl</name>
+	<range><lt>7.55.0</lt></range>
+      </package>
+    </affects>
+    <description>
+      <body xmlns="http://www.w3.org/1999/xhtml">
+	<p>The cURL project reports:</p>
+	<blockquote cite="https://curl.haxx.se/docs/security.html">
+	  <ul>
+	    <li><h2>FILE buffer read out of bounds</h2>
+	      <p>When asking to get a file from a file:// URL, libcurl provides
+		a feature that outputs meta-data about the file using HTTP-like
+		headers.</p>
+	      <p>The code doing this would send the wrong buffer to the user
+		(stdout or the application's provide callback), which could
+		lead to other private data from the heap to get inadvertently
+		displayed.</p>
+	      <p>The wrong buffer was an uninitialized memory area allocated on
+		the heap and if it turned out to not contain any zero byte, it
+		would continue and display the data following that buffer in
+		memory.</p>
+	    </li>
+	    <li><h2>TFTP sends more than buffer size</h2>
+	      <p>When doing a TFTP transfer and curl/libcurl is given a URL that
+		contains a very long file name (longer than about 515 bytes),
+		the file name is truncated to fit within the buffer boundaries,
+		but the buffer size is still wrongly updated to use the
+		untruncated length. This too large value is then used in the
+		sendto() call, making curl attempt to send more data than what
+		is actually put into the buffer. The sendto() function will then
+		read beyond the end of the heap based buffer.</p>
+	      <p>A malicious HTTP(S) server could redirect a vulnerable libcurl-
+		using client to a crafted TFTP URL (if the client hasn't
+		restricted which protocols it allows redirects to) and trick it
+		to send private memory contents to a remote server over UDP.
+		Limit curl's redirect protocols with --proto-redir and libcurl's
+		with CURLOPT_REDIR_PROTOCOLS.</p>
+	    </li>
+	    <li><h2>URL globbing out of bounds read</h2>
+	      <p>curl supports "globbing" of URLs, in which a user can pass a
+		numerical range to have the tool iterate over those numbers to
+		do a sequence of transfers.</p>
+	      <p>In the globbing function that parses the numerical range, there
+		was an omission that made curl read a byte beyond the end of the
+		URL if given a carefully crafted, or just wrongly written, URL.
+		The URL is stored in a heap based buffer, so it could then be
+		made to wrongly read something else instead of crashing.</p>
+	      <p>An example of a URL that triggers the flaw would be
+		http://ur%20[0-60000000000000000000.</p>
+	    </li>
+	  </ul>
+	</blockquote>
+      </body>
+    </description>
+    <references>
+      <url>https://curl.haxx.se/docs/security.html</url>
+      <cvename>CVE-2017-1000099</cvename>
+      <cvename>CVE-2017-1000100</cvename>
+      <cvename>CVE-2017-1000101</cvename>
+    </references>
+    <dates>
+      <discovery>2017-08-09</discovery>
+      <entry>2017-08-09</entry>
+    </dates>
+  </vuln>
+
   <vuln vid="c1265e85-7c95-11e7-93af-005056925db4">
     <topic>Axis2 -- Security vulnerability on dependency Apache Commons FileUpload</topic>
     <affects>
