Hi Axel, On Sat, Aug 07, 2021 at 03:51:07AM +0200, Axel Beckert wrote: > Hi, > > On Fri, Aug 06, 2021 at 05:14:32PM +0000, Thorsten Glaser > <t...@mirbsd.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@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:p...@www.example.org > ^^^^^^^^^^ > > From Wiresharks "Follow TCP stream": > > ...........a > ....jV.. ......../.......D.&....R.+.,..... . > .../.0...............z.{./.5.A... > .....|.}.3.9.E.............2.8.D.......p............$."...user:p...@www.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.
MITRE did assign CVE-2021-38165. MITRE raised the question: Does 2.9.0dev.9 (mentioned on the https://lynx.invisible-island.net/current/CHANGES.html page) fix the entire problem? https://www.openwall.com/lists/oss-security/2021/08/07/7 claims that credentials appear in the HTTP Host header to an http:// (i.e., non-SSL) website. Regards, Salvatore
