Re: [oss-security] Re: Bug#991971: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Ariadne Conill <[email protected]>
| Newsgroups | gmane.comp.web.lynx.devel,gmane.comp.security.oss.general |
|---|---|
| Message-ID | <[email protected]> |
Hi, On Sat, 7 Aug 2021, Axel Beckert wrote: > Hi Salvatore, Dear Ariadne, > > Salvatore Bonaccorso wrote: >>> 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. > […] >>> IMHO this nevertheless needs a CVE-ID. >> >> MITRE did assign CVE-2021-38165. > > Thanks Salvatore. I updated the debian/changelog entry for the next > upload as well as the title of the Debian bug report. +1, thanks for getting a CVE for this. >> 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? > > At this point a huge thanks to Thomas Dickey (Lynx upstream) for > providing a fixed version so quickly! I think 2.9.0dev.9 fixes the problem, even if the fix is, well, not the way I would do it. > >> 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. > > Indeed and a good point. > > Citing from Ariadne's mail: >> The issue itself is far more severe: HTParse() does not understand >> the authn part of the URI at all. > […] >> But it will also leak in the Host: header on unencrypted >> connections, and also probably SSL ones too. > > But that looks to me as if Ariadne just refers to the code and hasn't > actually checked it by trying it. Nevertheless thanks to Ariadne for > having had a look and proposing a patch! Yes, this was my guess since HTParse() doesn't understand the authn part. But this seems like a rather unfortunate design: parse the URI wrong, and then "fix" it later? Why not just parse the URI right, to begin with? So strange... Ariadne _______________________________________________ Lynx-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lynx-dev