Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

Katherine Mcmillan <[email protected]>
Newsgroups gmane.os.freebsd.security.general
Message-ID <YTXPR0101MB12291D09D7F6F1D597CB4956E8F49@YTXPR0101MB1229.CANPRD01.PROD.OUTLOOK.COM>
FYI

________________________________
From: Lynx-dev <[email protected]> on behalf of Ariadne Conill <[email protected]>
Sent: 07 August 2021 10:17
To: [email protected] <[email protected]>
Cc: Axel Beckert <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>
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:[email protected]", "", PARSE_HOST)

It returns:

   foo:[email protected]

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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[email protected]"
fix-auth-data-leaks.patch (text/plain, 1.4 KB)
--- 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 */
ATT00001.txt (text/plain, 141 B)
_______________________________________________
Lynx-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lynx-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.