bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Katherine Mcmillan
kmcmi046 at uottawa.ca
Sat Aug 7 15:06:53 UTC 2021
FYI
________________________________
From: Lynx-dev <lynx-dev-bounces+kmcmi046=uottawa.ca at nongnu.org> on behalf of Ariadne Conill <ariadne at dereferenced.org>
Sent: 07 August 2021 10:17
To: oss-security at lists.openwall.com <oss-security at lists.openwall.com>
Cc: Axel Beckert <abe at debian.org>; lynx-dev at nongnu.org <lynx-dev at nongnu.org>; security at debian.org <security at debian.org>; 991971 at bugs.debian.org <991971 at bugs.debian.org>
Subject: Re: [Lynx-dev] [oss-security] Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Attention : courriel externe | external email
Hi,
On Sat, 7 Aug 2021, Thorsten Glaser wrote:
> Axel Beckert dixit:
>
>> 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
>
> I *ALWAYS* SAID SNI IS A SHIT THING ONLY USED AS BAD EXCUSE FOR NAT
> BY PEOPLE WHO ARE TOO STUPID TO CONFIGURE THEIR SERVERS RIGHT AND AS
> BAD EXCUSE FOR LACKING IPv6 SUPPORT, AND THEN THE FUCKING IDIOTS WENT
> AND MADE SNI *MANDATORY* FOR TLSv1.3, AND I FEEL *SO* VINDICATED RIGHT
> NOW! IDIOTS IN CHARGE OF SECURITY, FUCKING IDIOTS…
It turns out SNI is only marginally related to this issue. The issue
itself is far more severe: HTParse() does not understand the authn part of
the URI at all. And so, when you call:
HTParse("https://foo:bar@example.com", "", PARSE_HOST)
It returns:
foo:bar at example.com
Which is then handed directly to SSL_set_tlsext_host_name() or
gnutls_server_name_set(). But it will also leak in the Host: header on
unencrypted connections, and also probably SSL ones too.
As a workaround, I taught HTParse() how to parse the authn part of URIs,
but Lynx itself needs to actually properly support the authn part really.
I have attached the patch Alpine is using to work around this infoleak.
Ariadne
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-auth-data-leaks.patch
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20210807/702c5238/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20210807/702c5238/attachment.txt>
More information about the freebsd-security
mailing list