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

Axel Beckert <[email protected]> Sat, 7 Aug 2021 03:51:07 +0200

Newsgroups	gmane.comp.web.lynx.devel,gmane.comp.security.oss.general
Organization	The Debian Project
Message-ID	<[email protected]>

Hi,

On Fri, Aug 06, 2021 at 05:14:32PM +0000, Thorsten Glaser
<[email protected]> wrote in
https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg00000.html:
> this affects both OpenSSL and Debian’s nonGNUtls builds:
> 
> lynx https://user:pass@host/
> 
> … will lead to…
> 
> SSL error:host(user:pass@host)!=cert(CN<mainhost>:SAN<DNS=host>:SAN<DNS=otherhost>
> 
> … for OpenSSL lynx and…
> 
> SSL error:host(user:pass@host)!=cert(CN<mainhost>)-Continue? (n)
> 
> … for nonGNUtls lynx.
> 
> Obviously, user:pass@ need to be stripped before comparing.

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
_before_ I can even said "n" for "no, don't continue to talk with this
server" in Lynx's prompt as shown above.

I was able to capture the password given on the commandline in traffic
of an TLS handshake using tcpdump and analysing it with Wireshark:

From Wiresharks TLS dissector:

Server Name Indication extension
    Server Name list length: 28
    Server Name Type: host_name (0)
    Server Name length: 25
    Server Name: user:[email protected]
                 ^^^^^^^^^^

From Wiresharks "Follow TCP stream":

...........a
....jV.. ......../.......D.&....R.+.,.....	.
.../.0...............z.{./.5.A...
.....|.}.3.9.E.............2.8.D.......p............$."...user:[email protected]......#...
...
.................
..............................

(PCAPs available on request. Actually did the test with a local server
of mine. But it should be easy to reproduce, be it with any Linux
distribution.)

I did this test with Lynx from Debian Experimental (which has the
current Lynx upstream release 2.9.0dev.8) as well as with Lynx from
Debian 8 Jessie ELTS (which has Lynx 2.8.9dev.1) and both leak the
password via SNI. I though assume that older releases of Lynx are
probably also affected as well, at least if they or the according
crypto libraries support SNI.

But given that the symptoms Thorsten discovered stayed unreported for
quite some years, I assume that this use case is a rather seldom one.
Nevertheless only trying to use Lynx that way (and seeing it fail)
already leaks the used password.

IMHO this nevertheless needs a CVE-ID.

Cc'ing Debian Security Team as well as the OSS Security mailing list
for making them aware of this issue. I also updated the subject of
this thread to make it less ambigous on other mailing lists.

And I'm also Cc'ing the according Debian bug report which I created
for tracking this issue in Debian: https://bugs.debian.org/991971

		Kind regards, Axel
-- 
 ,''`.  |  Axel Beckert <[email protected]>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

_______________________________________________
Lynx-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lynx-dev

signature.asc (application/pgp-signature, 833 B)