Date: Sat, 7 Aug 2021 15:06:45 +0000 From: Katherine Mcmillan <kmcmi046@uottawa.ca> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances) Message-ID: <YTXPR0101MB12291D09D7F6F1D597CB4956E8F49@YTXPR0101MB1229.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <ab519dc0-7354-8e5-8855-ffea2534ea34@dereferenced.org> References: <Pine.BSM.4.64L.2108061711590.28219@herc.mirbsd.org> <20210807015102.ea4f5immh2l5ku4n@sym.noone.org> <Pine.BSM.4.64L.2108070210210.904@herc.mirbsd.org>, <ab519dc0-7354-8e5-8855-ffea2534ea34@dereferenced.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
FYI
________________________________
From: Lynx-dev <lynx-dev-bounces+kmcmi046=uottawa.ca@nongnu.org> on behalf of Ariadne Conill <ariadne@dereferenced.org>
Sent: 07 August 2021 10:17
To: oss-security@lists.openwall.com <oss-security@lists.openwall.com>
Cc: Axel Beckert <abe@debian.org>; lynx-dev@nongnu.org <lynx-dev@nongnu.org>; security@debian.org <security@debian.org>; 991971@bugs.debian.org <991971@bugs.debian.org>
Subject: Re: [Lynx-dev] [oss-security] Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Attention : courriel externe | external email
Hi,
On Sat, 7 Aug 2021, Thorsten Glaser wrote:
> Axel Beckert dixit:
>
>> This is more severe than it initially looked like: Due to TLS Server
>> Name Indication (SNI) the hostname as parsed by Lynx (i.e with
>> "user:pass@" included) is sent in _clear_ text over the wire even
>
> I *ALWAYS* SAID SNI IS A SHIT THING ONLY USED AS BAD EXCUSE FOR NAT
> BY PEOPLE WHO ARE TOO STUPID TO CONFIGURE THEIR SERVERS RIGHT AND AS
> BAD EXCUSE FOR LACKING IPv6 SUPPORT, AND THEN THE FUCKING IDIOTS WENT
> AND MADE SNI *MANDATORY* FOR TLSv1.3, AND I FEEL *SO* VINDICATED RIGHT
> NOW! IDIOTS IN CHARGE OF SECURITY, FUCKING IDIOTS…
It turns out SNI is only marginally related to this issue. The issue
itself is far more severe: HTParse() does not understand the authn part of
the URI at all. And so, when you call:
HTParse("https://foo:bar@example.com", "", PARSE_HOST)
It returns:
foo:bar@example.com
Which is then handed directly to SSL_set_tlsext_host_name() or
gnutls_server_name_set(). But it will also leak in the Host: header on
unencrypted connections, and also probably SSL ones too.
As a workaround, I taught HTParse() how to parse the authn part of URIs,
but Lynx itself needs to actually properly support the authn part really.
I have attached the patch Alpine is using to work around this infoleak.
Ariadne
[-- Attachment #2 --]
--- lynx2.8.9rel.1.orig/WWW/Library/Implementation/HTParse.c
+++ lynx2.8.9rel.1/WWW/Library/Implementation/HTParse.c
@@ -31,6 +31,7 @@
struct struct_parts {
char *access;
+ char *auth;
char *host;
char *absolute;
char *relative;
@@ -121,6 +122,18 @@
}
/*
+ * Scan left-to-right for an authentication username/password combination (auth).
+ */
+ for (p = after_access; *p; p++) {
+ if (*p == '@') {
+ parts->auth = after_access;
+ *p = '\0';
+ after_access = (p + 1); /* advance base pointer forward */
+ break;
+ }
+ }
+
+ /*
* Scan left-to-right for a fragment (anchor).
*/
for (p = after_access; *p; p++) {
@@ -135,10 +148,14 @@
* Scan left-to-right for a host or absolute path.
*/
p = after_access;
- if (*p == '/') {
- if (p[1] == '/') {
- parts->host = (p + 2); /* host has been specified */
- *p = '\0'; /* Terminate access */
+ if (*p == '/' || parts->auth) {
+ if (p[1] == '/' || parts->auth) {
+ if (!parts->auth) {
+ parts->host = (p + 2); /* host has been specified */
+ *p = '\0'; /* Terminate access */
+ } else {
+ parts->host = p;
+ }
p = StrChr(parts->host, '/'); /* look for end of host name if any */
if (p != NULL) {
*p = '\0'; /* Terminate host */
[-- Attachment #3 --]
_______________________________________________
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR0101MB12291D09D7F6F1D597CB4956E8F49>