Bug in Lynx's SSL certificate validation – leaks password in clear text via SNI

https://www.openwall.com/lists/oss-security/2021/08/07/1

by jwilk • 5 years ago

202 65 5 years ago

Forge36• 5 years ago

Any mitigation?

hannob• 5 years ago

I guess if you use lynx to surf to http basic auth URLs you should switch to another browser until a security update is available. But I'm inclined to say while this is an interesting bug I don't think that's an incredibly common scenario.

Update: It seems there's a preliminary patch that will not fix http auth URLs, but will prevent the info leak: https://www.openwall.com/lists/oss-security/2021/08/07/7

infogulch4• 5 years ago

Plain auth websites are pretty uncommon these days. That said, if using other authentication methods are annoying or inconvenient in Lynx (I don't know, I've never used it) then there may be some correlation between Lynx users and plain auth websites meaning this could impact a large fraction of Lynx the userbase.

tinus_hn• 5 years ago

Http basic authentication urls are never secure (that requires https) and are not supported in links by browsers these days.

kadoban• 5 years ago

Don't use urls like https://user:pass@example.com

infogulch4• 5 years ago

This is my understanding from reading the OP. Lynx is a CLI browser and apparently it sends plain-auth credentials in the clear in the SNI/hostname part of the https/tls handshake. I suppose someone forgot that the authority part of a uri has a slot for both userinfo as well as host, and parsed it wrong. [0]

As far as mitigations go, I guess any of these would work: don't use Lynx; don't use SNI (???); don't use plain auth.

[0] https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Sy...

Koshkin• 5 years ago

Somehow I have never got around to liking Lynx. But I love (the textmode) links and use it every day. Any reasons why Lynx can be a better choice?

cuillevel3• 5 years ago

Not sure. I think it's just older.

Back then, when I still cared about textmode browsers, there was lynx. Then came w3m and links and they were the cool new stuff.

throwawayboise• 5 years ago

w3m is pretty good at layout and in particular at tables. I use emacs for my mail, and use w3m to render html email and it does about as well as I think is possible within the confines of fixed-font plain text.

Mister_Snuggles2• 5 years ago

My first exposure to the internet was via Edmonton FreeNet. You'd dial in, using a terminal program like a BBS, and it would dump you into Lynx.

They had a menu where you could access email (Pine), manage your small amount of file space (downloads went here, then you'd go to the file manager to transfer them to your computer via ZModem), change your password, etc.

I have fond memories of Lynx, but I haven't used it since I switched to a provider that gave me a "real" connection.

forgotmypw17• 5 years ago

Lynx is more lightweight, has a slightly different keyboard shortcut setup, and is much more explicit about displaying various HTTP messages in a way the user can see them. It also has confirmations for cookies by default.

anthk2• 5 years ago

Gopher holes with HTTP links everywhere, such as gopherddit or hngopher.

slim• 5 years ago

For me, muscle memory. I used Lynx back in the day on my 386 running DOS. And it's been useful everytime I had to install a linux system without installer (last time was guix, if I remember correctly). First thing I do is put it in expert mode to recover 3 lines at the bottom of the screen (you press "o" for options)

opheliate4• 5 years ago

I happened to go to the Lynx Wikipedia page on seeing this news - I never realised it was based on libwww, the original library written by Tim Berners-Lee and Jean-François Groff for HTTP clients back in 1992. Presumably the fork is pretty much unrecognisable at this point, but what an incredible heritage!

tialaramex8• 5 years ago

I ALWAYS SAID SNI IS A SHIT THING ONLY USED AS BAD EXCUSE FOR NAT [...] I FEEL SO VINDICATED RIGHT NOW!

Thorsten Glaser appears to be another from the BSD school of "perfect" programmers who are held back by the inadequacies of literally everybody and everything else in the world. If only the TLS protocol was designed by Thorsten, and everybody else used it the way Thorsten thinks they should, then this program would be correct so it's not really his fault, it's our fault. See?

Nah, SNI is a rather recent thing. But…

This "rather recent thing" was standardised in 2003 and thus is old enough that if it were human it could vote in a lot of the world. But it's true that in some versions of Lynx it wasn't available until July 2018. They only had three years to identify this gross parsing bug.

mtlynch• 5 years ago

I was confused about the source of this quote because it's not in OP, so for anyone else curious:

https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg00...

ndkwj• 5 years ago

We must overcomplicate everything until there can only be one implementation of each standard

asddubs• 5 years ago

okay, but being able to use only one SSL certificate for each IP fucking sucks

dane-pgp• 5 years ago

^ Found the Google Chrome dev.

wyager2• 5 years ago

I would agree with you if the *BSD people didn’t tend to put out vastly higher-quality software than most of the other stuff out there.

judge2020• 5 years ago

As evidenced by this bug :)

Mister_Snuggles2• 5 years ago

This bug seems to have nothing to do with SNI or TLS, it is all about how Lynx parses the URL and what pieces it incorrectly passes to the underlying TLS library.

stjohnswarts2• 5 years ago

Please source your quotes.

jwilk• 5 years ago

The quote is from the next message in the thread, i.e.:

https://www.openwall.com/lists/oss-security/2021/08/07/2

dang2• 5 years ago

"Please don't fulminate."

https://news.ycombinator.com/newsguidelines.html

Also, please don't cross into personal attack. You can make your substantive points without that.

Y_Y• 5 years ago

What kind of Saxon genitive is that? Please fix to "Lynx's".

dang2• 5 years ago

Lol. Fixed. Thank!

opheliate4• 5 years ago

Let me say, I really appreciate OpenSSL, and it's made amazing progress in terms of security over the last few years. I make monthly donations to the developers as I believe it's critical infrastructure. Buutt...

From [0], the issue arises when they send "user:pass@host" to SSL_set_tlsext_host_name, which happily sets the SNI to whatever it's given [1]. As a point of comparison, when you create a Rustls client via ClientSession::new [2], you have to pass it a DNSNameRef, which will validate that there's no auth component in the string it wraps, and return an error if you try to set the server name to something involving auth details.

I'm sure there's reasons why OpenSSL is set up to work like this, but I can't see why anyone would ever want to send those auth details in the clear in the SNI, and I wish it provided an API that would anticipate this misuse, like in Rust. The OpenSSL docs don't indicate it's an issue you should think about when invoking this function [3].

I realise I'm picking on OpenSSL here, and GnuTLS appears to do the exact same thing. I'm just not certain anyone not wearing a hazmat suit and being watched by multiple other trained professionals should be handling OpenSSL code.

0: https://www.openwall.com/lists/oss-security/2021/08/07/7

1: https://github.com/openssl/openssl/blob/5cbd2ea3f94aa8adec9b...

2: https://docs.rs/rustls/0.19.1/rustls/struct.ClientSession.ht...

3: https://www.openssl.org/docs/man1.1.1/man3/SSL_set_tlsext_ho...

ziml77• 5 years ago

Does this mean that they've never been parsing URLs correctly? Kind of crazy if that's the case since a web browser would be the last place I'd expect to find such a basic URL processing issue.

opheliate4• 5 years ago

I would think that this was introduced at the same time as SNI was enabled for Lynx (2009-04-26 from the changelog, but I haven’t checked if it was actually vulnerable at that time). I don’t know if I’d call any URL processing issue basic though, I can safely say that I’m never even going to attempt to write a URL parser, just because of the number of potential edge cases. You can imagine when you’re enabling a (fairly simple, compared to the rest of the TLS spec) extension, you might not be thinking about all the different quirks of the URL spec which could occur and mess up what seems like a basic change.

kevin_thibedeau3• 5 years ago

OpenSSL isn't an HTTPS library. It's TLS and agnostic to any higher level protocol. It's not their job to filter strings with rules that may not apply for every use case.

ctz2• 5 years ago

SNI is specified to only take DNS hostnames. Not bits of URL. DNS hostnames only. OpenSSL and gnutls are faulty in this respect.

ctz2• 5 years ago

During the development of rustls, we also found a similar bug in Apple's TLS stack. We reported that to Apple and they fixed it.

So it is feasible -- at scale -- for TLS clients to validate that DNS names in the SNI extension really are DNS names, and are not IP addresses or bits of URL.

opheliate4• 5 years ago

Thank you so much for your work on rustls by the way, such a great library, and the results of the last audit were very impressive :)

zinekeller• 5 years ago

During the development of rustls, we also found a similar bug in Apple's TLS stack.

Was Windows' Schannel also tested? Or this is simply due to the dev team having access to Linux and macOS?

anthk2• 5 years ago

Lynx has already been patched.

Bug in Lynx's SSL certificate validation – leaks password in clear text via SNI

Related Stories