I have found a remote buffer overflow in Lynx. It occurs when a Lynx user selects malicious links or simply visits malicious web pages! When Lynx connects to an NNTP server to fetch information about the available articles in a newsgroup, it will call a function called HTrjis() with the information from certain article headers. The function adds missing ESC characters to certain data, to support Asian character sets. However, it does not check if it writes outside of the char array buf, and that causes a remote stack-based buffer overflow, with full control over EIP, EBX, EBP, ESI and EDI. Two attack vectors to make a victim visit a URL to a dangerous news server are: (a) *redirecting scripts*, where the victim visits some web page and it redirects automatically to a malicious URL, and (b) *links in web pages*, where the victim visits some web page and selects a link on the page to a malicious URL. Attack vector (b) is helped by the fact that Lynx does not automatically display where links lead to, unlike many graphical web browsers. A victim is in danger when his or her Lynx session is forced to visit a URL of the types "nntp://some.news.server/group.name" or "news:group.name", and the server that Lynx connects to must send back article headers with certain malicious data. It may be possible to make real news servers distribute such articles without technical problems, but that has not been tested. The vulnerable versions are at least 2.8.5, 2.8.6dev.13, 2.8.4 and 2.8.3. The old version 2.8.2 is not vulnerable. I have attached a malicious NNTP server that exhibits this problem. (As noted above, it might be possible to exploit this issue through legitimate news servers as well.) You just run this server, then you start Lynx with a URL of the type "nntp://malicious.server/group.name", and it will crash immediately. To test the attack vectors, I have also included a redirecting script and a web page with a link to a malicious server. Finally, I have attached a patch for this issue. It simply stops copying when it comes close to the end of the array. (I thought about expanding the size of the array, but I thought that might have repercussions in other parts of the code.) I hope that we can coordinate our respective updates for Lynx by agreeing on a release date. // Ulf Harnhammar for the Debian Security Audit Project
I have found a remote buffer overflow in Lynx. It occurs when a Lynx user selects malicious links or simply visits malicious web pages! When Lynx connects to an NNTP server to fetch information about the available articles in a newsgroup, it will call a function called HTrjis() with the information from certain article headers. The function adds missing ESC characters to certain data, to support Asian character sets. However, it does not check if it writes outside of the char array buf, and that causes a remote stack-based buffer overflow, with full control over EIP, EBX, EBP, ESI and EDI. Two attack vectors to make a victim visit a URL to a dangerous news server are: (a) *redirecting scripts*, where the victim visits some web page and it redirects automatically to a malicious URL, and (b) *links in web pages*, where the victim visits some web page and selects a link on the page to a malicious URL. Attack vector (b) is helped by the fact that Lynx does not automatically display where links lead to, unlike many graphical web browsers. A victim is in danger when his or her Lynx session is forced to visit a URL of the types "nntp://some.news.server/group.name" or "news:group.name", and the server that Lynx connects to must send back article headers with certain malicious data. It may be possible to make real news servers distribute such articles without technical problems, but that has not been tested. The vulnerable versions are at least 2.8.5, 2.8.6dev.13, 2.8.4 and 2.8.3. The old version 2.8.2 is not vulnerable. I have attached a malicious NNTP server that exhibits this problem. (As noted above, it might be possible to exploit this issue through legitimate news servers as well.) You just run this server, then you start Lynx with a URL of the type "nntp://malicious.server/group.name", and it will crash immediately. To test the attack vectors, I have also included a redirecting script and a web page with a link to a malicious server. Finally, I have attached a patch for this issue. It simply stops copying when it comes close to the end of the array. (I thought about expanding the size of the array, but I thought that might have repercussions in other parts of the code.) I hope that we can coordinate our respective updates for Lynx by agreeing on a release date. // Ulf Harnhammar for the Debian Security Audit Project http://www.debian.org/security/audit/
Created attachment 70132 [details, diff] lynx.security.patch
New patch from Thomas Dickey <dickey@his.com> up at: ftp://invisible-island.net/temp/lynx2.8.6dev.13e-special.patch.gz Deedra, please attach an updated ebuild. Do NOT commit anything to portage.
Trying seemant instead.
I'll have something up for you guys shortly
ok, so thomas' patch applies to the current development version of lynx (2.8.6dev13). I've asked him if he has a backport, else I'll be trying to backport this myself to 2.8.5 (I'll probably need to bring Spanky or solar into the picture to verify). Thanks,
Created attachment 70451 [details] new ebuild for lynx This is the new ebuild
Created attachment 70452 [details, diff] Thomas Dickey's patch, back-ported to 2.8.5 This is the patch -- please place into ${FILESDIR} for testing purposes. For release, this will go onto mirrors.
Thx Seemant. Calling arch security liaisons for testing: alpha kloeri amd64 blubb hppa hansmi ppc hansmi ppc64 tgall sparc gustavoz x86 tester Please test and report back on this bug.
Looks sane for sparc.
seems to work fine on amd64 too
Looks good on ppc and hppa
Status so far. Good on: sparc, amd64, ppc and hppa
Still missing alpha, ppc64 and x86 tests. Adding rangerpb to handle ppc64.
Looks good for ppc64
looks good on x86
Alpha is good.
OK, all ready to be committed directly stable at disclosure date. seemant: that should be sometime tomorrow.
This is public now, please commit the updated ebuild. I'll open a new bug or remove restrictions on this one when I get up to date on my bug inbox later today.
Opening.
it's in portage now.
Thx everyone. GLSA 200510-15