mirror/freebsd-ports
1
0
Fork 0
mirror of https://git.FreeBSD.org/ports.git synced 2025-01-28 10:08:24 +00:00
Code Issues Releases Activity

security/vuxml: Document 2 vulnerabilities in ftp/curl

Browse Source 
Security:	CVE-2021-22876
		CVE-2021-22890

PR:		254772
Reported by:	yasu@utahime.org
This commit is contained in:
Thomas Zander 2021-04-10 08:24:55 +02:00
parent 1819ba3057
commit 1e8993822a
1 changed files with 87 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
security/vuxml/vuln.xml
View File

@ -76,6 +76,93 @@ Notes:
* Do not forget port variants (linux-f10-libxml2, libxml2, etc.)
-->
<vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
<vuln vid="d10fc771-958f-11eb-9c34-080027f515ea">
<topic>curl -- TLS 1.3 session ticket proxy host mixup</topic>
<affects>
<package>
<name>curl</name>
<range><ge>7.63.0</ge><lt>7.76.0</lt></range>
</package>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>Daniel Stenberg reports:</p>
<blockquote cite="https://curl.se/docs/CVE-2021-22890.html">
<p>
Enabled by default, libcurl supports the use of TLS 1.3 session
tickets to resume previous TLS sessions to speed up subsequent
TLS handshakes.
</p>
<p>
When using a HTTPS proxy and TLS 1.3, libcurl can confuse session
tickets arriving from the HTTPS proxy but work as if they arrived
from the remote server and then wrongly "short-cut" the host
handshake. The reason for this confusion is the modified sequence
from TLS 1.2 when the session ids would provided only during the
TLS handshake, while in TLS 1.3 it happens post hand-shake and
the code was not updated to take that changed behavior into account.
</p>
<p>
When confusing the tickets, a HTTPS proxy can trick libcurl to use
the wrong session ticket resume for the host and thereby circumvent
the server TLS certificate check and make a MITM attack to be
possible to perform unnoticed.
</p>
<p>
This flaw can allow a malicious HTTPS proxy to MITM the traffic.
Such a malicious HTTPS proxy needs to provide a certificate that
curl will accept for the MITMed server for an attack to work -
unless curl has been told to ignore the server certificate check.
</p>
</blockquote>
</body>
</description>
<references>
<cvename>CVE-2021-22890</cvename>
<url>https://curl.se/docs/CVE-2021-22890.html</url>
</references>
<dates>
<discovery>2021-03-31</discovery>
<entry>2021-04-10</entry>
</dates>
</vuln>
<vuln vid="b1194286-958e-11eb-9c34-080027f515ea">
<topic>curl -- Automatic referer leaks credentials</topic>
<affects>
<package>
<name>curl</name>
<range><ge>7.1.1</ge><lt>7.76.0</lt></range>
</package>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>Daniel Stenberg reports:</p>
<blockquote cite="https://curl.se/docs/CVE-2021-22876.html">
<p>
libcurl does not strip off user credentials from the URL when
automatically populating the Referer: HTTP request header field
in outgoing HTTP requests, and therefore risks leaking sensitive
data to the server that is the target of the second HTTP request.
</p>
<p>
libcurl automatically sets the Referer: HTTP request header field
in outgoing HTTP requests if the CURLOPT_AUTOREFERER option is set.
With the curl tool, it is enabled with --referer ";auto".
</p>
</blockquote>
</body>
</description>
<references>
<cvename>CVE-2021-22876</cvename>
<url>https://curl.se/docs/CVE-2021-22876.html</url>
</references>
<dates>
<discovery>2021-03-31</discovery>
<entry>2021-04-10</entry>
</dates>
</vuln>
<vuln vid="8ba23a62-997d-11eb-9f0e-0800278d94f0">
<topic>gitea -- multiple vulnerabilities</topic>
<affects>