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
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.