Bug#991971: [oss-security] Re: Bug#991971: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Ariadne Conill]

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

Bug#991971: [oss-security] Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Ariadne Conill]

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:b...@example.com;, "", PARSE_HOST)

It returns:

  foo:b...@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--- lynx2.8.9rel.1.orig/WWW/Library/Implementation/HTParse.c
+++ lynx2.8.9rel.1/WWW/Library/Implementation/HTParse.c
@@ -31,6 +31,7 @@
 
 struct struct_parts {
 char *access;
+char *auth;
 char *host;
 char *absolute;
 char *relative;
@@ -121,6 +122,18 @@
 }
 
 /*
+ * Scan left-to-right for an authentication username/password combination 
(auth).
+ */
+for (p = after_access; *p; p++) {
+   if (*p == '@') {
+   parts->auth = after_access;
+   *p = '\0';
+   after_access = (p + 1); /* advance base pointer forward */
+   break;
+   }
+}
+
+/*
  * Scan left-to-right for a fragment (anchor).
  */
 for (p = after_access; *p; p++) {
@@ -135,10 +148,14 @@
  * Scan left-to-right for a host or absolute path.
  */
 p = after_access;
-if (*p == '/') {
-   if (p[1] == '/') {
-   parts->host = (p + 2);  /* host has been specified*/
-   *p = '\0';  /* Terminate access   */
+if (*p == '/' || parts->auth) {
+   if (p[1] == '/' || parts->auth) {
+if (!parts->auth) {
+parts->host = (p + 2); /* host has been specified*/
+*p = '\0'; /* Terminate access   */
+} else {
+parts->host = p;
+}
p = StrChr(parts->host, '/');   /* look for end of host name if 
any */
if (p != NULL) {
*p = '\0';  /* Terminate host */

Bug#977130: sh4: ELF interpreter not installed in correct location

[Ariadne Conill]

Package: musl
Version: 1.2.1-1
Severity: important

Hello,

When compiling software with musl for an sh4 target, the software is linked with
an ELF interpreter of /lib/ld-musl-sh.so.1.  The Debian package, however, 
installs
/lib/ld-musl-sh4.so.1 as the interpreter path.

Musl 1.2.2 release is due out shortly; please consider fixing (or adding a 
symlink)
the ELF interpreter path on sh4 architecture.

Ariadne


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: sh4 (in qemu-user)

Kernel: Linux 5.4.79-0-lts (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect