From owner-svn-ports-head@freebsd.org Wed Jun 24 17:59:42 2020 Return-Path: Delivered-To: svn-ports-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D85A6355DB8; Wed, 24 Jun 2020 17:59:42 +0000 (UTC) (envelope-from sunpoet@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49sWBP3SvHz3ZQk; Wed, 24 Jun 2020 17:59:40 +0000 (UTC) (envelope-from sunpoet@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8F23515CAE; Wed, 24 Jun 2020 17:59:39 +0000 (UTC) (envelope-from sunpoet@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 05OHxdp6025658; Wed, 24 Jun 2020 17:59:39 GMT (envelope-from sunpoet@FreeBSD.org) Received: (from sunpoet@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 05OHxdDp025657; Wed, 24 Jun 2020 17:59:39 GMT (envelope-from sunpoet@FreeBSD.org) Message-Id: <202006241759.05OHxdDp025657@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: sunpoet set sender to sunpoet@FreeBSD.org using -f From: Sunpoet Po-Chuan Hsieh Date: Wed, 24 Jun 2020 17:59:39 +0000 (UTC) To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r540335 - head/security/vuxml X-SVN-Group: ports-head X-SVN-Commit-Author: sunpoet X-SVN-Commit-Paths: head/security/vuxml X-SVN-Commit-Revision: 540335 X-SVN-Commit-Repository: ports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 17:59:43 -0000 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.) --> + + curl -- multiple vulnerabilities + + + curl + 7.20.07.71.0 + + + + +

curl security problems:

+
CVE-2020-8169: Partial password leak over DNS on HTTP redirect
+
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).
+
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.
+
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.
+
If the options are set, they override the credentials set in the + URL.
+
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.
+
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.
+
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.
+
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).
+
CVE-2020-8177: curl overwrite local file with -J
+
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.
+
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.
+
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.
+
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.
+
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.
+
(Also note that -J needs to be used in combination with -O to have + any effect.)
+

+ + + + https://curl.haxx.se/docs/security.html + https://curl.haxx.se/docs/CVE-2020-8169.html + https://curl.haxx.se/docs/CVE-2020-8177.html + CVE-2020-8169 + CVE-2020-8177 + + + 2020-06-24 + 2020-06-24 + + + CUPS -- memory corruption