svn commit: r540335 - head/security/vuxml
Sunpoet Po-Chuan Hsieh
sunpoet at FreeBSD.org
Wed Jun 24 17:59:43 UTC 2020
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>
More information about the svn-ports-all
mailing list