Date: Wed, 24 Jun 2020 17:59:39 +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: r540335 - head/security/vuxml Message-ID: <202006241759.05OHxdDp025657@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: sunpoet Date: Wed Jun 24 17:59:38 2020 New Revision: 540335 URL: https://svnweb.freebsd.org/changeset/ports/540335 Log: Document curl vulnerability Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Wed Jun 24 17:59:32 2020 (r540334) +++ head/security/vuxml/vuln.xml Wed Jun 24 17:59:38 2020 (r540335) @@ -58,6 +58,98 @@ Notes: * Do not forget port variants (linux-f10-libxml2, libxml2, etc.) --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">; + <vuln vid="6bff5ca6-b61a-11ea-aef4-08002728f74c"> + <topic>curl -- multiple vulnerabilities</topic> + <affects> + <package> + <name>curl</name> + <range><ge>7.20.0</ge><lt>7.71.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-8169: Partial password leak over DNS on HTTP redirect</p> + <p>libcurl can be tricked to prepend a part of the password to the + host name before it resolves it, potentially leaking the partial + password over the network and to the DNS server(s).</p> + <p>libcurl can be given a username and password for HTTP + authentication when requesting an HTTP resource - used for HTTP + Authentication such as Basic, Digest, NTLM and similar. The + credentials are set, either together with CURLOPT_USERPWD or + separately with CURLOPT_USERNAME and CURLOPT_PASSWORD. Important + detail: these strings are given to libcurl as plain C strings and + they are not supposed to be URL encoded.</p> + <p>In addition, libcurl also allows the credentials to be set in the + URL, using the standard RFC 3986 format: + http://user:password@host/path. In this case, the name and password + are URL encoded as that's how they appear in URLs.</p> + <p>If the options are set, they override the credentials set in the + URL.</p> + <p>Internally, this is handled by storing the credentials in the "URL + object" so that there is only a single set of credentials stored + associated with this single URL.</p> + <p>When libcurl handles a relative redirect (as opposed to an + absolute URL redirect) for an HTTP transfer, the server is only + sending a new path to the client and that path is applied on to the + existing URL. That "applying" of the relative path on top of an + absolute URL is done by libcurl first generating a full absolute + URL out of all the components it has, then it applies the redirect + and finally it deconstructs the URL again into its separate + components.</p> + <p>This security vulnerability originates in the fact that curl did + not correctly URL encode the credential data when set using one of + the curl_easy_setopt options described above. This made curl + generate a badly formatted full URL when it would do a redirect and + the final re-parsing of the URL would then go bad and wrongly + consider a part of the password field to belong to the host name.</p> + <p>The wrong host name would then be used in a name resolve lookup, + potentially leaking the host name + partial password in clear text + over the network (if plain DNS was used) and in particular to the + used DNS server(s).</p> + <p>CVE-2020-8177: curl overwrite local file with -J</p> + <p>curl can be tricked by a malicious server to overwrite a local + file when using -J (--remote-header-name) and -i (--include) in the + same command line.</p> + <p>The command line tool offers the -J option that saves a remote + file using the file name present in the Content-Disposition: + response header. curl then refuses to overwrite an existing local + file using the same name, if one already exists in the current + directory.</p> + <p>The -J flag is designed to save a response body, and so it doesn't + work together with -i and there's logic that forbids it. However, + the check is flawed and doesn't properly check for when the options + are used in the reversed order: first using -J and then -i were + mistakenly accepted.</p> + <p>The result of this mistake was that incoming HTTP headers could + overwrite a local file if one existed, as the check to avoid the + local file was done first when body data was received, and due to + the mistake mentioned above, it could already have received and + saved headers by that time.</p> + <p>The saved file would only get response headers added to it, as it + would abort the saving when the first body byte arrives. A + malicious server could however still be made to send back virtually + anything as headers and curl would save them like this, until the + first CRLF-CRLF sequence appears.</p> + <p>(Also note that -J needs to be used in combination with -O to have + any effect.)</p> + </blockquote> + </body> + </description> + <references> + <url>https://curl.haxx.se/docs/security.html</url>; + <url>https://curl.haxx.se/docs/CVE-2020-8169.html</url>; + <url>https://curl.haxx.se/docs/CVE-2020-8177.html</url>; + <cvename>CVE-2020-8169</cvename> + <cvename>CVE-2020-8177</cvename> + </references> + <dates> + <discovery>2020-06-24</discovery> + <entry>2020-06-24</entry> + </dates> + </vuln> + <vuln vid="ce0c8590-b628-11ea-9d28-3c970ee9157c"> <topic>CUPS -- memory corruption</topic> <affects>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202006241759.05OHxdDp025657>