Date: Wed, 19 Aug 2020 16:26:33 +0000 (UTC) From: Sunpoet Po-Chuan Hsieh <sunpoet@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r545438 - head/security/vuxml Message-ID: <202008191626.07JGQXmL083571@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: sunpoet Date: Wed Aug 19 16:26:33 2020 New Revision: 545438 URL: https://svnweb.freebsd.org/changeset/ports/545438 Log: Document curl vulnerability Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Wed Aug 19 16:26:27 2020 (r545437) +++ head/security/vuxml/vuln.xml Wed Aug 19 16:26:33 2020 (r545438) @@ -58,6 +58,57 @@ Notes: * Do not forget port variants (linux-f10-libxml2, libxml2, etc.) --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1"> + <vuln vid="b905dff4-e227-11ea-b0ea-08002728f74c"> + <topic>curl -- expired pointer dereference vulnerability</topic> + <affects> + <package> + <name>curl</name> + <range><ge>7.29.0</ge><lt>7.72.0</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml"> + <p>curl security problems:</p> + <blockquote cite="https://curl.haxx.se/docs/security.html"> + <p>CVE-2020-8231: wrong connect-only connection</p> + <p>An application that performs multiple requests with libcurl's multi API + and sets the CURLOPT_CONNECT_ONLY option, might in rare circumstances + experience that when subsequently using the setup connect-only transfer, + libcurl will pick and use the wrong connection - and instead pick + another one the application has created since then.</p> + <p>CURLOPT_CONNECT_ONLY is the option to tell libcurl to not perform an + actual transfer, only connect. When that operation is completed, libcurl + remembers which connection it used for that transfer and "easy handle". + It remembers the connection using a pointer to the internal connectdata + struct in memory.</p> + <p>If more transfers are then done with the same multi handle before the + connect-only connection is used, leading to the initial connect-only + connection to get closed (for example due to idle time-out) while also + new transfers (and connections) are setup, such a new connection might + end up getting the exact same memory address as the now closed + connect-only connection.</p> + <p>If after those operations, the application then wants to use the + original transfer's connect-only setup to for example use + curl_easy_send() to send raw data over that connection, libcurl could + erroneously find an existing connection still being alive at the address + it remembered since before even though this is now a new and different + connection.</p> + <p>The application could then accidentally send data over that connection + which wasn't at all intended for that recipient, entirely unknowingly.</p> + </blockquote> + </body> + </description> + <references> + <url>https://curl.haxx.se/docs/security.html</url> + <url>https://curl.haxx.se/docs/CVE-2020-8231.html</url> + <cvename>CVE-2020-8231</cvename> + </references> + <dates> + <discovery>2020-08-19</discovery> + <entry>2020-08-19</entry> + </dates> + </vuln> + <vuln vid="3fcb70a4-e22d-11ea-98b2-080027846a02"> <topic>Python -- multiple vulnerabilities</topic> <affects>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202008191626.07JGQXmL083571>