Bugzilla Bug 108451

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 an attachment (id=70132) [edit]
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 an attachment (id=70451) [edit]
new ebuild for lynx

This is the new ebuild

Created an attachment (id=70452) [edit]
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