Lines 78-83
Notes:
Link Here
|
78 |
* Do not forget port variants (linux-f10-libxml2, libxml2, etc.) |
78 |
* Do not forget port variants (linux-f10-libxml2, libxml2, etc.) |
79 |
--> |
79 |
--> |
80 |
<vuxml xmlns="http://www.vuxml.org/apps/vuxml-1"> |
80 |
<vuxml xmlns="http://www.vuxml.org/apps/vuxml-1"> |
|
|
81 |
<vuln vid="d10fc771-958f-11eb-9c34-080027f515ea"> |
82 |
<topic>curl -- TLS 1.3 session ticket proxy host mixup</topic> |
83 |
<affects> |
84 |
<package> |
85 |
<name>curl</name> |
86 |
<range><ge>7.63.0</ge><lt>7.76.0</lt></range> |
87 |
</package> |
88 |
</affects> |
89 |
<description> |
90 |
<body xmlns="http://www.w3.org/1999/xhtml"> |
91 |
<p>Daniel Stenberg reports:</p> |
92 |
<blockquote cite="https://curl.se/docs/CVE-2021-22890.html"> |
93 |
<p> |
94 |
Enabled by default, libcurl supports the use of TLS 1.3 session |
95 |
tickets to resume previous TLS sessions to speed up subsequent |
96 |
TLS handshakes. |
97 |
</p> |
98 |
<p> |
99 |
When using a HTTPS proxy and TLS 1.3, libcurl can confuse session |
100 |
tickets arriving from the HTTPS proxy but work as if they arrived |
101 |
from the remote server and then wrongly "short-cut" the host |
102 |
handshake. The reason for this confusion is the modified sequence |
103 |
from TLS 1.2 when the session ids would provided only during the |
104 |
TLS handshake, while in TLS 1.3 it happens post hand-shake and |
105 |
the code was not updated to take that changed behavior into account. |
106 |
</p> |
107 |
<p> |
108 |
When confusing the tickets, a HTTPS proxy can trick libcurl to use |
109 |
the wrong session ticket resume for the host and thereby circumvent |
110 |
the server TLS certificate check and make a MITM attack to be |
111 |
possible to perform unnoticed. |
112 |
</p> |
113 |
<p> |
114 |
This flaw can allow a malicious HTTPS proxy to MITM the traffic. |
115 |
Such a malicious HTTPS proxy needs to provide a certificate that |
116 |
curl will accept for the MITMed server for an attack to work - |
117 |
unless curl has been told to ignore the server certificate check. |
118 |
</p> |
119 |
</blockquote> |
120 |
</body> |
121 |
</description> |
122 |
<references> |
123 |
<cvename>CVE-2021-22890</cvename> |
124 |
<url>https://curl.se/docs/CVE-2021-22890.html</url> |
125 |
</references> |
126 |
<dates> |
127 |
<discovery>2021-03-31</discovery> |
128 |
<entry>2021-04-04</entry> |
129 |
</dates> |
130 |
</vuln> |
131 |
|
132 |
<vuln vid="b1194286-958e-11eb-9c34-080027f515ea"> |
133 |
<topic>curl -- Automatic referer leaks credentials</topic> |
134 |
<affects> |
135 |
<package> |
136 |
<name>curl</name> |
137 |
<range><ge>7.1.1</ge><lt>7.76.0</lt></range> |
138 |
</package> |
139 |
</affects> |
140 |
<description> |
141 |
<body xmlns="http://www.w3.org/1999/xhtml"> |
142 |
<p>Daniel Stenberg reports:</p> |
143 |
<blockquote cite="https://curl.se/docs/CVE-2021-22876.html"> |
144 |
<p> |
145 |
libcurl does not strip off user credentials from the URL when |
146 |
automatically populating the Referer: HTTP request header field |
147 |
in outgoing HTTP requests, and therefore risks leaking sensitive |
148 |
data to the server that is the target of the second HTTP request. |
149 |
</p> |
150 |
<p> |
151 |
libcurl automatically sets the Referer: HTTP request header field |
152 |
in outgoing HTTP requests if the CURLOPT_AUTOREFERER option is set. |
153 |
With the curl tool, it is enabled with --referer ";auto". |
154 |
</p> |
155 |
</blockquote> |
156 |
</body> |
157 |
</description> |
158 |
<references> |
159 |
<cvename>CVE-2021-22876</cvename> |
160 |
<url>https://curl.se/docs/CVE-2021-22876.html</url> |
161 |
</references> |
162 |
<dates> |
163 |
<discovery>2021-03-31</discovery> |
164 |
<entry>2021-04-04</entry> |
165 |
</dates> |
166 |
</vuln> |
167 |
|
81 |
<vuln vid="1f6d97da-8f72-11eb-b3f1-005056a311d1"> |
168 |
<vuln vid="1f6d97da-8f72-11eb-b3f1-005056a311d1"> |
82 |
<topic>samba -- Multiple Vulnerabilities</topic> |
169 |
<topic>samba -- Multiple Vulnerabilities</topic> |
83 |
<affects> |
170 |
<affects> |