Mishandling the userinfo subcomponent of a URI allows remote attackers to discover cleartext credentials because they may appear in SNI data.
Created lynx tracking bugs for this issue:
Affects: fedora-all [bug 1994999]
Created attachment 1815719 [details]
Extracted from lynx 2.9.0dev.9.
This issue was caused by incorrect extraction of server host names from URLs for use during TLS/SSL connection handshakes. If URL contained userinfo part, i.e. authentication credentials, embedded in URLs as http://user:email@example.com, the extracted hostname included not only "server.name", but also the credentials part "user:firstname.lastname@example.org". This value was used during verification of server identity and would often cause verification to fail due to connection hostname not matching name stored in server certificate. Verification could still succeed for wild card certificates. The value was also included as part of the Server Name Indication (SNI) TLS extension data and sent unencrypted as part of the Client Hello packet during the TLS connection handshake. This is how authentication credentials could have been exposed to an attacker able to eavesdrop on the network connection between the lynx browser and the server.
This issue did not affect lynx version in Red Hat Enterprise Linux 6, as SNI support was first added to lynx in version 2.8.7pre2:
Note that this issue can not be exploited by having a victim visit a malicious URL or page prepared by an attacker, as such URL or any link on such page would only contain credentials already known to an attacker. The issue is only relevant in cases when a user uses lynx to access some trusted URL with credentials included as part of the URL, e.g. by following such link form some "bookmark" page. Hence an information leak can only happen when victim performs a specific action that is out of attacker's control.