Date: Wed, 17 Jun 2015 21:40:52 +0000 (UTC) From: Xin LI <delphij@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r389995 - head/security/vuxml Message-ID: <201506172140.t5HLeqUS048753@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: delphij Date: Wed Jun 17 21:40:51 2015 New Revision: 389995 URL: https://svnweb.freebsd.org/changeset/ports/389995 Log: Document two vulnerabilities of cURL. Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Wed Jun 17 20:16:43 2015 (r389994) +++ head/security/vuxml/vuln.xml Wed Jun 17 21:40:51 2015 (r389995) @@ -57,6 +57,77 @@ Notes: --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">; + <vuln vid="2438d4af-1538-11e5-a106-3c970e169bc2"> + <topic>cURL -- Multiple Vulnerability</topic> + <affects> + <package> + <name>curl</name> + <range><ge>7.40</ge><lt>7.43</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>cURL reports:</p> + <blockquote cite="http://curl.haxx.se/docs/adv_20150617A.html">; + <p>libcurl can wrongly send HTTP credentials when re-using + connections.</p> + <p>libcurl allows applications to set credentials for the + upcoming transfer with HTTP Basic authentication, like + with CURLOPT_USERPWD for example. Name and password. + Just like all other libcurl options the credentials + are sticky and are kept associated with the "handle" + until something is made to change the situation.</p> + <p>Further, libcurl offers a curl_easy_reset() function + that resets a handle back to its pristine state in + terms of all settable options. A reset is of course + also supposed to clear the credentials. A reset is + typically used to clear up the handle and prepare + it for a new, possibly unrelated, transfer.</p> + <p>Within such a handle, libcurl can also store a + set of previous connections in case a second transfer + is requested to a host name for which an existing + connection is already kept alive.</p> + <p>With this flaw present, using the handle even + after a reset would make libcurl accidentally use + those credentials in a subseqent request if done + to the same host name and connection as was + previously accessed.</p> + <p>An example case would be first requesting a password + protected resource from one section of a web site, and + then do a second request of a public resource from a + completely different part of the site without + authentication. This flaw would then inadvertently + leak the credentials in the second request.</p> + </blockquote> + <blockquote cite="http://curl.haxx.se/docs/adv_20150617B.html">; + <p>libcurl can get tricked by a malicious SMB server to + send off data it did not intend to.</p> + <p>In libcurl's state machine function handling the SMB + protocol (smb_request_state()), two length and offset + values are extracted from data that has arrived over + the network, and those values are subsequently used + to figure out what data range to send back.</p> + <p>The values are used and trusted without boundary + checks and are just assumed to be valid. This allows + carefully handicrafted packages to trick libcurl + into responding and sending off data that was not + intended. Or just crash if the values cause libcurl + to access invalid memory.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-3236</cvename> + <cvename>CVE-2015-3237</cvename> + <url>http://curl.haxx.se/docs/adv_20150617A.html</url>; + <url>http://curl.haxx.se/docs/adv_20150617B.html</url>; + </references> + <dates> + <discovery>2015-06-17</discovery> + <entry>2015-06-17</entry> + </dates> + </vuln> + <vuln vid="eb8a8978-8dd5-49ce-87f4-49667b2166dd"> <topic>rubygem-rails -- multiple vulnerabilities</topic> <affects>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201506172140.t5HLeqUS048753>