[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210807015102.ea4f5immh2l5ku4n@sym.noone.org>
Date: Sat, 7 Aug 2021 03:51:07 +0200
From: Axel Beckert <abe@...ian.org>
To: lynx-dev@...gnu.org
Cc: oss-security@...ts.openwall.com, security@...ian.org,
991971@...s.debian.org
Subject: Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks
password in clear text via SNI (under some circumstances)
Hi,
On Fri, Aug 06, 2021 at 05:14:32PM +0000, Thorsten Glaser
<tg@...bsd.de> 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@...t/
>
> … will lead to…
>
> SSL error:host(user:pass@...t)!=cert(CN<mainhost>:SAN<DNS=host>:SAN<DNS=otherhost>
>
> … for OpenSSL lynx and…
>
> SSL error:host(user:pass@...t)!=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:pass@....example.org
^^^^^^^^^^
From Wiresharks "Follow TCP stream":
...........a
....jV.. ......../.......D.&....R.+.,..... .
.../.0...............z.{./.5.A...
.....|.}.3.9.E.............2.8.D.......p............$."...user:pass@....example.org......#...
...
.................
..............................
(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 <abe@...ian.org>, 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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
