Debian Bug report logs -
#991971
lynx: [CVE-2021-38165] SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/\; leaks password in clear text via SNI
Report forwarded
to debian-bugs-dist@lists.debian.org, abe@debian.org, tg@debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Fri, 06 Aug 2021 21:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
New Bug report received and forwarded. Copy sent to abe@debian.org, tg@debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Fri, 06 Aug 2021 21:45:03 GMT) (full text, mbox, link).
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: lynx: SSL certificate validation fails with URLs containing user
name or user name and password, i.e. https://user:password@host/ and
https://user@host/
Date: Fri, 06 Aug 2021 23:43:13 +0200
Package: lynx
Version: 2.9.0dev.8-1
Severity: important
Tags: upstream, confirmed
Control: forwarded -1 https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg00000.html
Control: found -1 2.8.9dev1-2+deb8u1
Control: found -1 2.8.9dev11-1
Control: found -1 2.8.9rel.1-3
Control: found -1 2.9.0dev.6-2
Thorsten Glaser reported the following on the upstream dev mailing list
at https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg00000.html
(citing the parts that affect Debian, i.e. those when compiled against
GnuTLS and not OpenSSL):
> 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>)-Continue? (n)
>
> … for nonGNUtls lynx.
>
> Obviously, user:pass@ need to be stripped before comparing. The
> nonGNUtls version could also be changed to display the
> subjectAltName''s the certificate has like the OpenSSL one does (after
> my patch from ages ago; […]
https://user@host/ is affected as well.
I was able to reproduce this issue in Lynx in all currently (in some
way) supported releases of Debian back to Debian 8 Jessie with ELTS
support and also in the most recent version in Debian Experimental.
P.S. to Thorsten: Feel free to set yourself as submitter of this bug
report. ☺
-- System Information:
Debian Release: 11.0
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages lynx depends on:
ii libbsd0 0.11.3-1
ii libbz2-1.0 1.0.8-4
ii libc6 2.31-13
ii libgnutls30 3.7.1-5
ii libidn2-0 2.3.0-5
ii libncursesw6 6.2+20201114-2
ii libtinfo6 6.2+20201114-2
ii lynx-common 2.9.0dev.6-2
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages lynx recommends:
ii mime-support 3.66
lynx suggests no packages.
-- no debconf information
Marked as found in versions lynx-cur/2.8.9dev1-2+deb8u1.
Request was from Axel Beckert <abe@debian.org>
to submit@bugs.debian.org.
(Fri, 06 Aug 2021 21:45:04 GMT) (full text, mbox, link).
Marked as found in versions lynx/2.8.9dev11-1.
Request was from Axel Beckert <abe@debian.org>
to submit@bugs.debian.org.
(Fri, 06 Aug 2021 21:45:04 GMT) (full text, mbox, link).
Marked as found in versions lynx/2.8.9rel.1-3.
Request was from Axel Beckert <abe@debian.org>
to submit@bugs.debian.org.
(Fri, 06 Aug 2021 21:45:04 GMT) (full text, mbox, link).
Marked as found in versions lynx/2.9.0dev.6-2.
Request was from Axel Beckert <abe@debian.org>
to submit@bugs.debian.org.
(Fri, 06 Aug 2021 21:45:05 GMT) (full text, mbox, link).
Added tag(s) security.
Request was from Axel Beckert <abe@debian.org>
to control@bugs.debian.org.
(Sat, 07 Aug 2021 01:21:02 GMT) (full text, mbox, link).
Changed Bug title to 'lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI' from 'lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/'.
Request was from Axel Beckert <abe@debian.org>
to control@bugs.debian.org.
(Sat, 07 Aug 2021 01:21:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 01:54:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 01:54:03 GMT) (full text, mbox, link).
Hi,
On Fri, Aug 06, 2021 at 05:14:32PM +0000, Thorsten Glaser
<tg@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:pass@www.example.org
^^^^^^^^^^
From Wiresharks "Follow TCP stream":
...........a
....jV.. ......../.......D.&....R.+.,..... .
.../.0...............z.{./.5.A...
.....|.}.3.9.E.............2.8.D.......p............$."...user:pass@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.
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@debian.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
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 02:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 02:18:03 GMT) (full text, mbox, link).
Subject: Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks
password in clear text via SNI (under some circumstances)
Date: Sat, 7 Aug 2021 02:14:12 +0000 (UTC)
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…
>But given that the symptoms Thorsten discovered stayed unreported for
>quite some years, I assume that this use case is a rather seldom one.
Nah, SNI is a rather recent thing. But…
>IMHO this nevertheless needs a CVE-ID.
… it probably does. Other browsers also need checking.
Thanks for the detective work,
//mirabilos
--
<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 02:54:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 02:54:02 GMT) (full text, mbox, link).
Subject: SNI is a security vulnerability all by itself (was Re: [Lynx-dev]
bug in Lynx' SSL certificate validation -> leaks password in clear text via
SNI (under some circumstances))
Date: Sat, 7 Aug 2021 02:50:16 +0000 (UTC)
>Axel Beckert dixit:
>>IMHO this nevertheless needs a CVE-ID.
I wonder… perhaps the use of SNI, both in the TLSv1.3 standard
and in some TLSv1.2 implementations, should receive CVEs as well?
It certainly ought to be disabled by default. Perhaps add some
environment variable to enable SNI in the SSL library, and if
it’s not present or explicitly set to 0, disable SNI (which also
would disable TLSv1.3 as it requires SNI). Hmm, yes, this sounds
completely like a good idea.
(Considering SNI also leaks the vhost addressed by the end user,
which is otherwise hidden with wildcard certificates or grouped
with tone others in multi-subjectAltName certificates, it ought
to have been anyway.)
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 14:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Ariadne Conill <ariadne@dereferenced.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 14:30:03 GMT) (full text, mbox, link).
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@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
Added tag(s) fixed-upstream.
Request was from Thomas Dickey <dickey@his.com>
to control@bugs.debian.org.
(Sat, 07 Aug 2021 15:18:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 16:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Andreas Metzler <ametzler@bebt.de>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 16:03:03 GMT) (full text, mbox, link).
Subject: Re: Processed: Re: Bug#991971: [Lynx-dev] bug in Lynx' SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
On 2021-08-07 Debian Bug Tracking System <owner@bugs.debian.org> wrote:
> Processing commands for control@bugs.debian.org:
> > tags 991971 fixed-upstream
> Bug #991971 [lynx] lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI
> Added tag(s) fixed-upstream.
Hello,
I have just uploaded .9 to experimental. The deadline for bulleye
unblock requests has passed, so we will need to fix this by
security/point release.
@Fellow lynx-maintainers: Do you have a preferred branch name for
bullseye? I would go for "11_bullseye".
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Source: lynx
Source-Version: 2.9.0dev.9-1
Done: Andreas Metzler <ametzler@debian.org>
We believe that the bug you reported is fixed in the latest version of
lynx, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 991971@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated lynx package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 07 Aug 2021 17:45:43 +0200
Source: lynx
Architecture: source
Version: 2.9.0dev.9-1
Distribution: experimental
Urgency: high
Maintainer: Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Closes: 991971
Changes:
lynx (2.9.0dev.9-1) experimental; urgency=high
.
* New upstream version.
+ Strip user/password from ssl_host in HTLoadHTTP, incorrectly passed
as part of the server name indicator (Debian #991971) -TDDoes not
pass user/passwd. Closes: #991971
* Add b-d on pkg-config.
Checksums-Sha1:
936c46ae16375956d85fcc63d01e68e0cac376f7 2539 lynx_2.9.0dev.9-1.dsc
c87542a4b9f7d81f11f005a3a34c646061c13dc6 2746988 lynx_2.9.0dev.9.orig.tar.bz2
2cbf25603ec60b350e38c4beebcf87bb13aa855e 729 lynx_2.9.0dev.9.orig.tar.bz2.asc
e55d151e6acd62344e945ed8bf4df255ef5881b0 32572 lynx_2.9.0dev.9-1.debian.tar.xz
Checksums-Sha256:
de26f6e49a33ca7d4f2711c6d1f5661d611212308013a2c3cb810e469b06ba18 2539 lynx_2.9.0dev.9-1.dsc
6fd6dd3f57681ad58d3397c273b430a411ae049b367fd4909b3d70b722da501a 2746988 lynx_2.9.0dev.9.orig.tar.bz2
561a23b38d7a4bb9f6f07d059cac3e49b5e282921fbd7c6185987d210054d917 729 lynx_2.9.0dev.9.orig.tar.bz2.asc
36d8eb27dee8c6c3ffa2e37c06220f32983f144207dfa802c3ee627420c01b13 32572 lynx_2.9.0dev.9-1.debian.tar.xz
Files:
41dbb1222cc364cf37a808a143dfacea 2539 web optional lynx_2.9.0dev.9-1.dsc
6599a118a5f993bd7a27f62c7b660c33 2746988 web optional lynx_2.9.0dev.9.orig.tar.bz2
69cff165cc2878d2f0b957aa58cd39fb 729 web optional lynx_2.9.0dev.9.orig.tar.bz2.asc
9f088216ed650873a362f848b95319a7 32572 web optional lynx_2.9.0dev.9-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0uCSA5741Jbt9PpepU8BhUOCFIQFAmEOrB4ACgkQpU8BhUOC
FISCIA/6AnR+wqQzrjBopMEmBnFB7Ygxt1JZzFMyOFrNG+4xH+HPUsyvLs0XDM60
35XsgA6RQFvgcPr5OBirtkwFvHCq90rQInoZGriT/pS0XXiKWh1js9Gbx0C+Pp5W
7W/YBcUmJ5Y1kCArIFtnLNXmHspCwrqohqosOZNrMY08BRCopAVFbfbD24wFzpnl
DOfuVS/vQr5d1JaxVNfA3nlYEVouTEsJSa1mfYYKH9R97slOSEUJPusJsXDpGPF3
e0OvghEVC7oNdAsPvdTeiCEL+x3VcSIIeT13r1FTNIb09wMG8EoIlk8dtKyMnkMB
krLDQufca/JJ3F235558kz5NGBMoXnQhlrb4HXQeespm0t1zmxZYbmjkpS5O5WEw
gO0wfIAGkhQCvwf14H7mShU6OOhwMUblDE/UQAAP3B3ZlDv+C/1PGasul1586+Bd
vCdoCgzNMNddAwW/59pgmOtmfucYJAOBDoY6jSyn+8yvMBitXMeOlHY2KWNcJ6t9
XcsLaeII4yrAVMd5Tpc78hVhG9v93l29jcX6dsbGTFXD128FlIbRHUuTZs/6YKp+
W9XWcKmEC5yFdNvcmz9LPe0t3kh0t8L2X9aYT3by8k7kw6S3iwftliy7Xbm0y/ks
rWlmYsyKZuAFeVXLqVL6+z+S1STFnIAHBxYXAm6UwfD/QxMiHqs=
=Ods1
-----END PGP SIGNATURE-----
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 16:15:05 GMT) (full text, mbox, link).
Acknowledgement sent
to noloader@gmail.com:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 16:15:05 GMT) (full text, mbox, link).
Cc: Axel Beckert <abe@debian.org>, lynx-dev@nongnu.org,
Debian Security Team <security@debian.org>, 991971@bugs.debian.org
Subject: Re: [oss-security] SNI is a security vulnerability all by itself (was
Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in
clear text via SNI (under some circumstances))
Date: Sat, 7 Aug 2021 12:08:25 -0400
On Sat, Aug 7, 2021 at 8:29 AM Thorsten Glaser <tg@mirbsd.de> wrote:
>
> >Axel Beckert dixit:
>
> >>IMHO this nevertheless needs a CVE-ID.
>
> I wonder… perhaps the use of SNI, both in the TLSv1.3 standard
> and in some TLSv1.2 implementations, should receive CVEs as well?
As far as I know, the only problem associated with SNI is leaking the
server name to a passive adversary in TLS 1.2 and below. TLS 1.3 and
above provide for encrypted server names.
> It certainly ought to be disabled by default. Perhaps add some
> environment variable to enable SNI in the SSL library, and if
> it’s not present or explicitly set to 0, disable SNI (which also
> would disable TLSv1.3 as it requires SNI). Hmm, yes, this sounds
> completely like a good idea.
If you disable SNI, then you won't be able to setup an encrypted
channel. SNI is needed to setup the encrypted channel. During the
client_hello, the server needs to know which server/virtual host to
route the client_hello to.
The user:password@ is for the application layer or HTTP/HTTPS. It
should not be present in the transport layer. It is a bug in the
application layer, not the transport layer.
The transport layer does have a password based authentication scheme,
but it is going to be either Thomas Wu's Secure Remote Password (SRP)
or Preshared Key (PSK). SRP is based on Diffie-Hellman (something like
a^password), while PSK uses a symmetric cipher (something like
enc_k(password)).
> (Considering SNI also leaks the vhost addressed by the end user,
> which is otherwise hidden with wildcard certificates or grouped
> with tone others in multi-subjectAltName certificates, it ought
> to have been anyway.)
Yes, the client will learn the server's IP address. That is not
related to SNI. That's just how TLS works under the IETF's threat
model.
Maybe you are thinking of (or need) something like a Tor hidden
service. Transport Layer Security does not provide a guarantee like a
hidden service.
Wildcards are garbage. You should be wary of an operator that uses
them nowadays. A wildcard certificate could be used by an attacker to
have you connect to the receptionist's machine in the lobby running a
fake site rather than the organization's web server.
Jeff
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 18:21:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 18:21:02 GMT) (full text, mbox, link).
Subject: Re: Bug#991971: [Lynx-dev] bug in Lynx' SSL certificate validation
-> leaks password in clear text via SNI (under some circumstances)
Date: Sat, 7 Aug 2021 20:17:31 +0200
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
> <tg@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:pass@www.example.org
> ^^^^^^^^^^
>
> From Wiresharks "Follow TCP stream":
>
> ...........a
> ....jV.. ......../.......D.&....R.+.,..... .
> .../.0...............z.{./.5.A...
> .....|.}.3.9.E.............2.8.D.......p............$."...user:pass@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
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 18:57:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 18:57:02 GMT) (full text, mbox, link).
Cc: oss-security@lists.openwall.com, Axel Beckert <abe@debian.org>,
lynx-dev@nongnu.org, security@debian.org, 991971@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)
Date: Sat, 7 Aug 2021 18:49:57 +0000 (UTC)
Ariadne Conill dixit:
> 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.
Yes, of course. But without SNI, nothing would have been sent *in
plaintext* at all. The certificate validation fails¹, the connection
stops and the user is asked whether to continue.
① Tested on an OS without SNI in its libssl.
> 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.
Thanks!
I recall having to work manually to strip the port from the hostname
for SSL certificate validation, ages ago, but I had not tested with
HTTP Auth sites back then.
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Changed Bug title to 'lynx: [CVE-2021-38165] SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/\; leaks password in clear text via SNI' from 'lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI'.
Request was from Axel Beckert <abe@debian.org>
to control@bugs.debian.org.
(Sat, 07 Aug 2021 19:18:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 20:03:05 GMT) (full text, mbox, link).
Acknowledgement sent
to dickey@his.com:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 20:03:05 GMT) (full text, mbox, link).
On Sat, Aug 07, 2021 at 08:17:31PM +0200, Salvatore Bonaccorso wrote:
> Hi Axel,
...
> 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.
I considered that possibility, but (using Axel's hint on how he tested)
found nothing in the data shown in "Follow TCP Stream" for this case.
Perhaps you could explain how you've tested this case, and how to repeat
the results.
(the suggested patch by the way is unsuitable because it breaks the
known-to-be-insecure use of user credentials in a non-HTTPS URL)
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.netftp://ftp.invisible-island.net
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 20:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 20:15:02 GMT) (full text, mbox, link).
Subject: Re: [oss-security] Re: Bug#991971: [Lynx-dev] bug in Lynx' SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
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.
> 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!
> 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!
To be on the safe side I tested Lynx 2.9.0dev.6-2 as in Debian
Unstable/Testing (yet unpatched for CVE-2021-38165) and the (claimed
to be fixed) Lynx 2.9.0dev.9-1 as uploaded to Debian Experimental by
Andreas Metzler very recently (still only on incoming.debian.org,
fetched it from there). And I also tested Lynx 2.8.9dev1 from Debian 8
Jessie ELTS, the oldest compiled version of Lynx I could easily get my
hands on.
Neither of them leaked the user name or password in Host header of a
plain HTTP request. (So I assume that the versions inbetween don't do
that either.)
I also kinda would have expected that if this would have been the case
in the plain HTTP Host header, it would have been noticed way earlier
than with the TLS SNI extension, namely before the HTTPS era. Then
again, the much more obvious facet of this issue which Thorsten
initially found was reported way later than I'd expected, so maybe my
gut feeling is wrong here, too. :-)
So I also looked in the code (of the unpatched 2.9.0dev.8). The patch
for 2.9.0dev.9 added a function StripUserAuthents and added it only
into the HTTPS code path. So I looked for "strip" and "Strip" in the
HTTP code path and found this code in WWW/Library/Implementation/HTTP.c
(which also has the HTTPS code btw.):
1353 if ((host = HTParse(anAnchor->address, "", PARSE_HOST)) != NULL) {
-> 1354 strip_userid(host, TRUE);
-> 1355 HTBprintf(&command, "Host: %s%c%c", host, CR, LF);
1356 FREE(host);
1357 }
So from my point of view, this also invalidates that claim that the
HTTP Host header contains username or password. HTParse (as mentioned
by Ariadne occurs quite often in the code and its exact workings are
unclear to me from just looking at how it is called as it seems very
variable in what it parses and it appears before and after the above
mentioned code snippet for printing the Host header.
$ fgrep -n 'HTParse(' WWW/Library/Implementation/HTTP.c
891: connect_host = HTParse(connect_url, "https", PARSE_HOST);
900: connect_host = HTParse(connect_url, "snews", PARSE_HOST);
977: ssl_host = HTParse(url, "", PARSE_HOST);
1319: char *p1 = (HTParse(url, "", PARSE_PATH | PARSE_PUNCTUATION));
1371: if ((host = HTParse(anAnchor->address, "", PARSE_HOST)) != NULL) {
1564: abspath = HTParse(arg, "", PARSE_PATH | PARSE_PUNCTUATION);
1565: docname = HTParse(arg, "", PARSE_PATH);
1566: hostname = HTParse(arg, "", PARSE_HOST);
1590: host2 = HTParse(docname, "", PARSE_HOST);
1591: path2 = HTParse(docname, "", PARSE_PATH | PARSE_PUNCTUATION);
2370: !HTAA_HaveUserinfo(HTParse(arg, "", PARSE_HOST)) &&
So from my point of view the user and password are stripped only once
(in 2.9.0dev8), namely directly before printing the Host header (in
both HTTP and HTTPS code paths). Which also seems the reason why it
got forgotten for SNI and why Thomas added a new, way less complex
function for stripping them of the SNI header. Calling strip_userid
again would extract the credentials again which likely isn't wanted.
(The same IMHO applies to the often called HTParse function.)
I assume that Ariadne just oversaw that call to strip_userid just
before printing the HTTP Host header when looking at the code. (And I
clearly had the advantage of having looked at the code _after_ the
official upstream patch has been published, so I clearly had an
advantage when looking at the code, too.)
I though didn't check the strip_userid function in detail as it's way
more complex than the rather simple StripUserAuthents function added
in 2.9.0dev.9. This likely because strip_userid does not only strip
those credentials, it also seems to extract them. And it clearly looks
for an "@" as delimiter. Together with the PCAPs of Lynx HTTP traffic
I analysed, I'm quite confident, that it's fine.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.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
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 20:30:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Ariadne Conill <ariadne@dereferenced.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 20:30:02 GMT) (full text, mbox, link).
Subject: Re: [oss-security] Re: Bug#991971: [Lynx-dev] bug in Lynx' SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
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
Severity set to 'serious' from 'important'
Request was from Axel Beckert <abe@debian.org>
to control@bugs.debian.org.
(Sat, 07 Aug 2021 23:33:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sat, 07 Aug 2021 23:57:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sat, 07 Aug 2021 23:57:03 GMT) (full text, mbox, link).
To: Andreas Metzler <ametzler@bebt.de>, 991971@bugs.debian.org
Cc: security@debian.org
Subject: Re: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
Hi Andreas,
Andreas Metzler wrote:
> > > tags 991971 fixed-upstream
> > Bug #991971 [lynx] lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI
> > Added tag(s) fixed-upstream.
>
> Hello,
>
> I have just uploaded .9 to experimental.
Thanks a lot! Went to bed in the morning last night, so I was really
happy to see at least Experimental already being fixed when I woke up
again.
> The deadline for bulleye unblock requests has passed, so we will
> need to fix this by security/point release.
Hrm, right, thanks for the reminder.
I nevertheless will update Unstable with a fix. It might be helpful
for the Security Team (Cc'ed) or us to prepare a stable-update for
Bullseye.
Security Team: Do you think the fix for CVE-2021-38165 should get a
DSA? Or do you think it's not important enough and we should target a
minor stable update for it?
> @Fellow lynx-maintainers: Do you have a preferred branch name for
> bullseye? I would go for "11_bullseye".
I'd just have said "bullseye" to keep things simple. But "11_bullseye"
isn't really bad either. At least the stable fix branches then would
be properly ordered. (I don't see much other gain from the "11_" in
front, though.)
The other option which came to my mind was "debian/bullseye" which I
thought would be according to DEP14, but then I noticed that it would
have to be "debian/bullseye-security" or "debian/bullseye-updates"
*sigh* according to DEP14.
But I must admit that I'm anything but a fan of DEP14. So I'll use
"11_bullseye".
Then again, this opens the question if I should put that upload to
Unstable into the 11_bullseye branch despite the later stable or
security update will not be a direct successor of that upload, at
least not in the debian/changelog. Meh. But then again, nothing speaks
against making it a predecessor in git only, i.e. just rewriting the
debian/changelog entry with the entry for the stable or security
update as the remainder will be the same anyways. And in the worst
case we can always rename branches or rewrite history in git. :-P
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.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
Source: lynx
Source-Version: 2.9.0dev.6-3
Done: Axel Beckert <abe@debian.org>
We believe that the bug you reported is fixed in the latest version of
lynx, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 991971@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Axel Beckert <abe@debian.org> (supplier of updated lynx package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 08 Aug 2021 02:27:54 +0200
Source: lynx
Architecture: source
Version: 2.9.0dev.6-3
Distribution: unstable
Urgency: high
Maintainer: Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Closes: 991971
Changes:
lynx (2.9.0dev.6-3) unstable; urgency=high
.
* Apply fix from Lynx 2.9.0dev.9 for CVE-2021-38165 to fix leakage of
username and password in the TLS 1.2 SNI Extension if username and
password were given in the URL, i.e. as https://user:pass@example.org/
(Closes: #991971)
Checksums-Sha1:
5f937346d99e0d01de955a829f751e4b6871175c 2528 lynx_2.9.0dev.6-3.dsc
6afae746bcf520c0804b2157225e4a249b3fddb4 30108 lynx_2.9.0dev.6-3.debian.tar.xz
c218df88acf8db06ba8a5fcfe389b976229dd12b 7461 lynx_2.9.0dev.6-3_amd64.buildinfo
Checksums-Sha256:
095581d1a918999debdd30b9f992e3a35c3f56ca38e1f73b897296024defa7c2 2528 lynx_2.9.0dev.6-3.dsc
45f6c27005c91b8cda7ac842718e94f91e94d634d8e900b725dbfa485fec64aa 30108 lynx_2.9.0dev.6-3.debian.tar.xz
767503cfcb00e5b44c860bd76d7404fdaf11cb217f41150627ccc143ef2a6871 7461 lynx_2.9.0dev.6-3_amd64.buildinfo
Files:
b10cfed6b228f4a3fef7ae3054cd6ab2 2528 web optional lynx_2.9.0dev.6-3.dsc
c98f545749c1dde4de8c6563103029c8 30108 web optional lynx_2.9.0dev.6-3.debian.tar.xz
114a847958642854386d66b0808e5903 7461 web optional lynx_2.9.0dev.6-3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERoyJeTtCmBnp12Ema+Zjx1o1yXUFAmEPLNcACgkQa+Zjx1o1
yXXskg/8CepC8oblzdBpFpQq94gQ9dYhSs2uweGcR3h7dTl0jWnU6yJMviHdRDM5
craRLo6boB5YsySFROwy2DqVa4il3M6bjzLFvTTMAz3+f7o5r89HgQuweq1HM7DJ
A1HPZFXXPRxbDK0fm/pzzzmOsjQ9XyCuBS/QgWiDLkZ0pcHB7cIET2snmkubd1gu
hfOeAw9ZXBwsM1zP+4p5RmzV+j4sMKy6pnQ1Rf5NMSo5/6OtYwseRNxWz3i0LqyC
VL0HCOaY7+LlZ3PgM1msHhjUG/utZhd/dqsDgEesEARpsR18ld+lm6nOlktSmMv4
MDrbZgBTkvbibhqIrWHfuwUYHmxFeDVeSy12BNMq06PaVRAx+fgblWKh4hf/1WNb
QCFg43HAXm1NjfrWx0upo2HXLrSb6/H2NbIh5dLv8Rmd2d2UbpW+ewv9B2Oy3B7Q
loG9ada5XxNIVUCa+/w3RIpy/0MWuxF2YVGqDJkEMdBM/g9jkINJyQ8tr9mWlOgG
G4wvP1S/W5nimisf5hx59H6lGlCmIz2LRDebBSd9DD3rKG51cPN8NrqD1G8mBy6+
DDFEGyknpAtku2haxJ5kvhbsytu+xVBM488Wo5svrsDehzhRwZFX8FCf/HG12xDc
hJlB75U7k9L1rYjKqDjGd13rLRMIX91wP0kGwXurDHDqHoo9YGg=
=OCyx
-----END PGP SIGNATURE-----
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sun, 08 Aug 2021 10:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Moritz Mühlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sun, 08 Aug 2021 10:03:03 GMT) (full text, mbox, link).
Cc: Andreas Metzler <ametzler@bebt.de>, 991971@bugs.debian.org,
security@debian.org
Subject: Re: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
Date: Sun, 8 Aug 2021 11:58:52 +0200
Am Sun, Aug 08, 2021 at 01:54:56AM +0200 schrieb Axel Beckert:
> Hi Andreas,
>
> Andreas Metzler wrote:
> > > > tags 991971 fixed-upstream
> > > Bug #991971 [lynx] lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/; leaks password in clear text via SNI
> > > Added tag(s) fixed-upstream.
> >
> > Hello,
> >
> > I have just uploaded .9 to experimental.
>
> Thanks a lot! Went to bed in the morning last night, so I was really
> happy to see at least Experimental already being fixed when I woke up
> again.
>
> > The deadline for bulleye unblock requests has passed, so we will
> > need to fix this by security/point release.
>
> Hrm, right, thanks for the reminder.
>
> I nevertheless will update Unstable with a fix. It might be helpful
> for the Security Team (Cc'ed) or us to prepare a stable-update for
> Bullseye.
>
> Security Team: Do you think the fix for CVE-2021-38165 should get a
> DSA? Or do you think it's not important enough and we should target a
> minor stable update for it?
This breaks a pretty fundamental security assumption for a browser, so
we should fix it via -security, even though lynx is a fringe browser.
bullseye-security is operational, so we can do both at the same time
so that bullseye will be fixed from day one.
Cheers,
Moritz
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sun, 08 Aug 2021 10:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sun, 08 Aug 2021 10:18:02 GMT) (full text, mbox, link).
Cc: Andreas Metzler <ametzler@bebt.de>, 991971@bugs.debian.org,
security@debian.org
Subject: Re: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
Hi Moritz,
Moritz Mühlenhoff wrote:
> > Security Team: Do you think the fix for CVE-2021-38165 should get a
> > DSA? Or do you think it's not important enough and we should target a
> > minor stable update for it?
>
> This breaks a pretty fundamental security assumption for a browser,
Ack.
> so we should fix it via -security, even though lynx is a fringe
> browser.
Good. Anything which gets the fix into bullseye (and preferably also
buster) rather sooner than later is fine for me.
> bullseye-security is operational, so we can do both at the same time
> so that bullseye will be fixed from day one.
That'd be great, thanks!
Feel free to base the security upload upon 2.9.0dev.6-3 which I
uploaded just recently. From my point of view nothing except the first
and last line of the debian/changelog entry needs to be changed for
bullseye-security.
I can also look into how well the patch applies to buster's version of
Lynx, but it might take until Monday.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.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
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sun, 08 Aug 2021 10:21:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sun, 08 Aug 2021 10:21:06 GMT) (full text, mbox, link).
Cc: Moritz Mühlenhoff <jmm@inutil.org>,
Andreas Metzler <ametzler@bebt.de>, 991971@bugs.debian.org,
security@debian.org
Subject: Re: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL
certificate validation -> leaks password in clear text via SNI (under some
circumstances)
Date: Sun, 8 Aug 2021 12:20:29 +0200
Axel,
On Sun, Aug 08, 2021 at 12:14:16PM +0200, Axel Beckert wrote:
> Hi Moritz,
>
> Moritz Mühlenhoff wrote:
> > > Security Team: Do you think the fix for CVE-2021-38165 should get a
> > > DSA? Or do you think it's not important enough and we should target a
> > > minor stable update for it?
> >
> > This breaks a pretty fundamental security assumption for a browser,
>
> Ack.
>
> > so we should fix it via -security, even though lynx is a fringe
> > browser.
>
> Good. Anything which gets the fix into bullseye (and preferably also
> buster) rather sooner than later is fine for me.
>
> > bullseye-security is operational, so we can do both at the same time
> > so that bullseye will be fixed from day one.
>
> That'd be great, thanks!
>
> Feel free to base the security upload upon 2.9.0dev.6-3 which I
> uploaded just recently. From my point of view nothing except the first
> and last line of the debian/changelog entry needs to be changed for
> bullseye-security.
Do I understand correctly you currently have not capactity to prepare
that upload? If so I can happily chime in, but if you as maintainr
will that will be perfectly preferable. If so: I suggest: just do a
~deb11u1 on top of the current unstable upload, with changelog entry
"Rebuild for bullseye-security", then pass -v2.9.0dev.6-2 to
dpkg-genchanges invocation, to include all changelog entries from
2.9.0dev.6-3 up to 2.9.0dev.6-3~deb11u1 in to changes file. Make sure
to build with -sa, as lynx/2.9.0dev.6 is new for dak on
security-master.
>
> I can also look into how well the patch applies to buster's version of
> Lynx, but it might take until Monday.
Thank you!
Salvatore
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Sun, 08 Aug 2021 10:33:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Sun, 08 Aug 2021 10:33:03 GMT) (full text, mbox, link).
To: Salvatore Bonaccorso <carnil@debian.org>, 991971@bugs.debian.org
Cc: Moritz Mühlenhoff <jmm@inutil.org>,
Andreas Metzler <ametzler@bebt.de>, security@debian.org
Subject: Re: [pkg-lynx-maint] Bug#991971: Bug#991971: [CVE-2021-38165] lynx:
bug in SSL certificate validation -> leaks password in clear text via SNI
(under some circumstances)
Hi Salvatore,
Salvatore Bonaccorso wrote:
> > > bullseye-security is operational, so we can do both at the same time
> > > so that bullseye will be fixed from day one.
> >
> > That'd be great, thanks!
> >
> > Feel free to base the security upload upon 2.9.0dev.6-3 which I
> > uploaded just recently. From my point of view nothing except the first
> > and last line of the debian/changelog entry needs to be changed for
> > bullseye-security.
>
> Do I understand correctly you currently have not capactity to prepare
> that upload?
Yes, but I also wasn't aware that I could do that upload.
> If so I can happily chime in, but if you as maintainr
> will that will be perfectly preferable.
I'm bit short of time for the rest of the day, so it'd be nice if
someone else could do that upload.
> If so: I suggest: just do a ~deb11u1 on top of the current unstable
> upload, with changelog entry "Rebuild for bullseye-security", then
> pass -v2.9.0dev.6-2 to dpkg-genchanges invocation, to include all
> changelog entries from 2.9.0dev.6-3 up to 2.9.0dev.6-3~deb11u1 in to
> changes file. Make sure to build with -sa, as lynx/2.9.0dev.6 is new
> for dak on security-master.
Interesting. I'd have done a 2.9.0dev.6-2+deb11u1 by reusing the
2.9.0dev.6-3 upload and just modifying the changelog entry. I thought
that would be cleaner. But I'm fine with both variants.
> > I can also look into how well the patch applies to buster's version of
> > Lynx, but it might take until Monday.
>
> Thank you!
Do they need to go into the same DSA?
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.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
Subject: Bug#991971: fixed in lynx 2.9.0dev.6-3~deb11u1
Date: Mon, 09 Aug 2021 21:18:51 +0000
Source: lynx
Source-Version: 2.9.0dev.6-3~deb11u1
Done: Andreas Metzler <ametzler@debian.org>
We believe that the bug you reported is fixed in the latest version of
lynx, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 991971@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated lynx package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 08 Aug 2021 13:36:32 +0200
Source: lynx
Architecture: source
Version: 2.9.0dev.6-3~deb11u1
Distribution: bullseye-security
Urgency: high
Maintainer: Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Closes: 991971
Changes:
lynx (2.9.0dev.6-3~deb11u1) bullseye-security; urgency=high
.
* Rebuild for bullseye-security.
.
lynx (2.9.0dev.6-3) unstable; urgency=high
.
* Apply fix from Lynx 2.9.0dev.9 for CVE-2021-38165 to fix leakage of
username and password in the TLS 1.2 SNI Extension if username and
password were given in the URL, i.e. as https://user:pass@example.org/
(Closes: #991971)
Checksums-Sha1:
d5ba3abe6c59ef3dc85557c37de7798222642cc3 2560 lynx_2.9.0dev.6-3~deb11u1.dsc
bc62d8915a0083c2fe4fa0dc5cf48fd9f83fd9b2 2730690 lynx_2.9.0dev.6.orig.tar.bz2
0517d1a5630ed147597fd350c68c4689ec2c12d2 265 lynx_2.9.0dev.6.orig.tar.bz2.asc
56d4346e26db3235a67ff934e1aab9c45a2929d8 30124 lynx_2.9.0dev.6-3~deb11u1.debian.tar.xz
Checksums-Sha256:
fb8cf8cfe9dbe879c25002fc670c8ca355f3ec37a91a66b5455e78f7fe344390 2560 lynx_2.9.0dev.6-3~deb11u1.dsc
78f0be7f81f4b84d8d33b45a05145f015e35355109be350e461de5c03abf53b2 2730690 lynx_2.9.0dev.6.orig.tar.bz2
22e3b7394187aef75c7a783f4f789ef8d68b9266a15e747d92bd914563a93180 265 lynx_2.9.0dev.6.orig.tar.bz2.asc
1086daa008f96775df5964341c77b1069b5233eeefbb7b577e49f45763918610 30124 lynx_2.9.0dev.6-3~deb11u1.debian.tar.xz
Files:
668fe9e0c5933c238db04d72a47d4cb2 2560 web optional lynx_2.9.0dev.6-3~deb11u1.dsc
86fa225340422f40a9a1a5c4243d8c91 2730690 web optional lynx_2.9.0dev.6.orig.tar.bz2
e56d1480fe48dbd3c39338038ba2430a 265 web optional lynx_2.9.0dev.6.orig.tar.bz2.asc
1bc51a1c4dc71f1ba7fba593df2e0505 30124 web optional lynx_2.9.0dev.6-3~deb11u1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0uCSA5741Jbt9PpepU8BhUOCFIQFAmEPxH0ACgkQpU8BhUOC
FIRM2w/+L0+Hz6dPyBsIVVL0PUnZoZUHCm05TUT1RB6NJsZ0mMOQbvEJwjzsnVbN
1wwZwUXJa5UgpCvhAfiXeGH2+zVn7S8UfVNQBTRzS8DiTdcrQMk4kjLsiJEac1TV
ih13c2XA9H7GYfXfYx6dqMBivERNH63O0XlwV0tESTyoy1++pPPhuETgFzs5KxUK
SXox1s9eVD0Ujj7dx4jaLtwlJfqqsYJuyGi+rkRR6UE5WR2S0jWtcEDWqCh0QdWP
lwPwC4pGxy6tzWkwbWaEetcI8qhzweQGkp1rUsfBoRczznrParlwWb7VwmCRxxF7
muiGG4OSZ2lWE1H1dV6yIKR314ds0xrYtPJ3LXNvXik4ZLp9zI3Ze+hZ6uc5RF2p
t7ax7Tn9dYy2JRRBYXZknKjMbwUpPo1fhRy/eIYz7zCo2CzpSmbhGWBIsYj8VZ8f
7Utg7YakxO2s0rsPcPy/W9f2ZfyrzMKB33MYDmE2lePhL0jYOzmpgbLJnDzKThHe
ai5mHthYycnVVPqiAA+XTh155im0DaHfeQcwXZ5BZ+37y0X0QwCMcjRdZ9evA6Tc
EcZV6Wbq63qULy1xaY2wB8uXJHXy2I6zU9IHpqIHID//IO2rDAFn7sMaAvmwN54/
/CvH4I1X4mIko34p6aFHu+yBMYzHHfsNfxRlaBdJdBTm7/LFDTg=
=ECuf
-----END PGP SIGNATURE-----
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>: Bug#991971; Package lynx.
(Tue, 10 Aug 2021 01:24:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>.
(Tue, 10 Aug 2021 01:24:02 GMT) (full text, mbox, link).
Cc: Andreas Metzler <ametzler@bebt.de>, 991971@bugs.debian.org,
security@debian.org
Subject: Re: Bug#991971: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx:
bug in SSL certificate validation -> leaks password in clear text via SNI
(under some circumstances)
Hi,
Axel Beckert wrote:
> I can also look into how well the patch applies to buster's version of
> Lynx, but it might take until Monday.
Done now, built with -sa, did a source-only uploaded to
security-master and pushed it into the branch 10_buster on Salsa
including the according git tag.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.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
Subject: Bug#991971: fixed in lynx 2.8.9rel.1-3+deb10u1
Date: Fri, 27 Aug 2021 11:19:43 +0000
Source: lynx
Source-Version: 2.8.9rel.1-3+deb10u1
Done: Axel Beckert <abe@debian.org>
We believe that the bug you reported is fixed in the latest version of
lynx, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 991971@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Axel Beckert <abe@debian.org> (supplier of updated lynx package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Tue, 10 Aug 2021 01:54:10 +0200
Source: lynx
Architecture: source
Version: 2.8.9rel.1-3+deb10u1
Distribution: buster-security
Urgency: high
Maintainer: Debian Lynx Packaging Team <pkg-lynx-maint@lists.alioth.debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Closes: 991971
Changes:
lynx (2.8.9rel.1-3+deb10u1) buster-security; urgency=high
.
* Apply fix from Lynx 2.9.0dev.9 for CVE-2021-38165 to fix leakage of
username and password in the TLS 1.2 SNI Extension if username and
password were given in the URL, i.e. as https://user:pass@example.org/
(Closes: #991971)
Checksums-Sha1:
f8c7f55657011b3a391a4b2a03bab682e3f7497f 2560 lynx_2.8.9rel.1-3+deb10u1.dsc
3e00ac30d008e0aa879bfd037abcfd9c0dd2faec 2689171 lynx_2.8.9rel.1.orig.tar.bz2
60ad87a45201396c291931d86411f35a8a4af97f 251 lynx_2.8.9rel.1.orig.tar.bz2.asc
e2f097c682aa263db6b72094ebc60f17e0c06811 29404 lynx_2.8.9rel.1-3+deb10u1.debian.tar.xz
4e3a35e0dbb518150f6890c33fde4ba77ea63566 7143 lynx_2.8.9rel.1-3+deb10u1_source.buildinfo
Checksums-Sha256:
bbab09e6482a4f433fc6063cc34f0353882b9fb4dfc10c8987959e58db00b312 2560 lynx_2.8.9rel.1-3+deb10u1.dsc
387f193d7792f9cfada14c60b0e5c0bff18f227d9257a39483e14fa1aaf79595 2689171 lynx_2.8.9rel.1.orig.tar.bz2
2cb6cf09763d58ec6951bc0bf4cf2836983756fb168f486d30f0a3921304408b 251 lynx_2.8.9rel.1.orig.tar.bz2.asc
0578691571d26b702748845e0acf2436e04b9c75b9e7d643465c23a1170bb8f4 29404 lynx_2.8.9rel.1-3+deb10u1.debian.tar.xz
fb0a2488cc3ad65e194f2fd9a74d74a6c517deac5808a72b9631c8001ee762d2 7143 lynx_2.8.9rel.1-3+deb10u1_source.buildinfo
Files:
ac5876d02e4878400ebbea60e6481107 2560 web optional lynx_2.8.9rel.1-3+deb10u1.dsc
44316f1b8a857b59099927edc26bef79 2689171 web optional lynx_2.8.9rel.1.orig.tar.bz2
d0cd3214b950926ddfc88a7c6d35cec8 251 web optional lynx_2.8.9rel.1.orig.tar.bz2.asc
e45c95752470dc4a06b9d9e4f0e865f6 29404 web optional lynx_2.8.9rel.1-3+deb10u1.debian.tar.xz
12020315232c68b3b4e1b58948e4ffb0 7143 web optional lynx_2.8.9rel.1-3+deb10u1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEERoyJeTtCmBnp12Ema+Zjx1o1yXUFAmERzU8ACgkQa+Zjx1o1
yXV+Eg/9HZMmVHM0424x4CN8idgGlTD82sO9Ht/5yyaa5TAkstQ35WS488Gr2SKU
GRUPiRQG3RIQ/1ae9hWKCB+BvQuhLkafFFoxiuQ+I5Z/scmyPkYqcc4IUgBgla/i
e+Q/zMhN62BxJyGKNRWR2Vty52dtOSlmkUFd/klynNGFehghLBWFSxnTRLbx3aer
EshAoW+MlnxbLoDMzCP4jfePzz6UWi/uG5LjZZ4N5GWzd4H6tEn4nwpkxOT2T/uy
9XqBaCwG7tIw34eZ3hgBRIHawV6aXvgeZPUAqI+unrbzeH2COkrTjhlem1ra1w+n
9HxbIyDlvKIuYMqjgL3kRQtUTHV9XA1/s0HgKmSOdiuEynm/ofvWhhIYdi+1AYQ/
E0zEFwVgQmPfGXzlnt0moFNWm+f5NijdHd//1vfUsH5RQCBn63FW+IfenTlzra6j
Q6n0NogzRu8nCdePrnstGRe2SXQUdzpGJjdNTTmZiW8DGqcwKy7OwgLkp+pqTJQq
Y3ruCsi37qaueAGI2RFU0WLvvOuqa2obF+APblzVcUeuLk5krL8ZDfk8cOP77Y7z
OTz6Lk+faDir9i782Zo2hg/bDXSMiSlrgNMhkQqW8684yRCzb2jCg4JapK73CcXs
ezXZ2PQYL8fm51sAIbBtskE/N0kQa/yBmg6t3zlio2pI/la8t4I=
=okwX
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Sun, 10 Oct 2021 07:27:55 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.