Bugzilla – Bug 121926
VUL-0: CVE-2005-3120: lynx: buffer overflow
Last modified: 2022-01-08 09:10:25 UTC
Hello Klaus, this reaches us via vendor-sec. From: Ulf Harnhammar <metaur@telia.com> To: dickey@his.com Cc: vendor-sec@lst.de, naddy@mips.inka.de Reply-To: metaur@telia.com User-Agent: Mutt/1.5.9i Subject: [vendor-sec] Lynx Remote Buffer Overflow Errors-To: vendor-sec-admin@lst.de Date: Sat, 8 Oct 2005 01:01:17 +0200 Lynx Remote Buffer Overflow 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/
CAN-2005-3120
From: Martin Schulze <joey@infodrom.org> To: Ulf Harnhammar <metaur@telia.com> Cc: dickey@his.com, vendor-sec@lst.de, naddy@mips.inka.de User-Agent: Mutt/1.5.9i Subject: [vendor-sec] Re: Lynx Remote Buffer Overflow Errors-To: vendor-sec-admin@lst.de Date: Sat, 8 Oct 2005 12:27:28 +0200 Ulf Harnhammar wrote: > On Sat, Oct 08, 2005 at 09:06:39AM +0200, Martin Schulze wrote: > > Ouch! Very well spotted! Thanks a lot. > > Please use CAN-2005-3120 for this issue. > > What about releasing this on Sunday the 16th of October? Any objections? Weekdays are usually better for most vendors, so October 17th would be a better day. Regards, Joey -- The only stupid question is the unasked one. _______________________________________________
From: Thomas Dickey <dickey@his.com> To: Ulf Harnhammar <metaur@telia.com> Cc: vendor-sec@lst.de, naddy@mips.inka.de Subject: [vendor-sec] Re: Lynx Remote Buffer Overflow Errors-To: vendor-sec-admin@lst.de Date: Sat, 8 Oct 2005 13:32:21 -0400 (EDT) On Sat, 8 Oct 2005, Ulf Harnhammar wrote: >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. Having reviewed the diff's, I disagree. 2.8.2 was vulnerable if you construct a different attack. The specific item we're talking about was exposing a lack of limit checks in decode_mime() descendents in 2.8.3dev.23 >I hope that we can coordinate our respective updates for Lynx by >agreeing on a release date. I've put a patch to address only this issue in ftp://invisible-island.net/temp/lynx2.8.6dev.13e-special.patch.gz which will be part of lynx 2.8.6dev.14 -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net _______________________________________________
Created attachment 53596 [details] lynx-backported.txt
issue is public
Thanks. Was in vacation. Will work on it as scheduling and time permits.
Thomas: I'm missing the mentioned special.patch.gz ------------------------------------------------------------------------ ncftpget ftp://invisible-island.net/temp/lynx2.8.6dev.13e-special.patch.gz ncftpget: server said: lynx2.8.6dev.13e-special.patch.gz: No such file or directory ------------------------------------------------------------------------ Thomas: where do I get the original patch for lynx2.8.6?
Created attachment 54774 [details] lynx-data.zip Archive: lynx-data.zip testing: link.html OK testing: lynx-nntp-server.pl OK testing: lynx.security.patch OK testing: redir.php OK No errors detected in compressed data of lynx-data.zip.
ftp://invisible-island.net/temp/ did not contain the patch anymore. Here is an Ubuntu patch. http://security.ubuntu.com/ubuntu/pool/main/l/lynx/lynx_2.8.5-1ubuntu1.1.diff.gz Size/MD5: 17668 c5251ad9cead60e416cf21a461371877
fixed packages submitted. all maintained products affected. security-team, please handle rest of process. thanks in advance.
Maintenance-Tracker-2644
/work/src/done/PATCHINFO/lynx.patch.maintained /work/src/done/PATCHINFO/lynx.patch.box
SUSE QA: The bug is apparently not fixed on ia64 and s390. When running the exploiting nttp server from this bugreport lynx still aborts: lynx nntp://poincare.suse.de/alt.angst ----------------------------------------------------- A Fatal error has occurred in Lynx Ver. 2.8.5rel.1 Please notify your system administrator to confirm a bug, and if confirmed, to notify the lynx-dev list. Bug reports should have concise descriptions of the command and/or URL which causes the problem, the operating system name with version number, the TCPIP implementation, and any other relevant information. Do NOT mail the core file if one was generated. Lynx now exiting with signal: 11 Aborted ----------------------------------------------------- Backtrace: ----------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x4000000000177550 in HTSACopy () (gdb) where #0 0x4000000000177550 in HTSACopy () #1 0x4000000000180c40 in HTmmdecode () #2 0x400000000018cde0 in decode_mime () #3 0x4000000000198680 in HTLoadNews () #4 0x40000000001325e0 in HTLoadDocument () #5 0x40000000001345e0 in HTLoadAbsolute () #6 0x40000000000504f0 in getfile () #7 0x400000000006ab50 in mainloop () #8 0x400000000005ae80 in main () (gdb) ----------------------------------------------------- All other platforms (i386, x86_64, s390x, ppc) do work.
The problem was a broken upstream patch for lynx version 2-8-5 lynx version 2-8-4 instead was fixed correct. So I submitted new packages for 9.1 (SLES9), 9.2, 9.3, 10.0 SLES8, 9.0 are affected by the problem itself; but didn't need a fix for the broken patch. Try again. :-) and: Sorry.
np. new sles9 patchinfo submitted, box restarted.
was approved and released.
CVE-2005-3120: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)