Re: LYNX-DEV /dev/null and the CERT bug

[Jonathan Sergent]

Scott wrote:
 ] After my note regarding testing of the CERT bug messing up /dev/null on my
 ] machine, there was some speculation that it was only due to my ability to
 ] use root priviledges. Let me caution everyone that a normal user account
 ] can and has trash /dev/null on some machines when testing Lynx with the
 ] CERT bug. At least on Solaris 2.4 this has been adequately demonstrated. If
 ] you have tested the CERT bug with Lynx on your system, be sure to check that
 ] /dev/null is correct and functional.

You probably shouldn't run lynx while su'ed to (or logged in as) root
in the first place, just on general principle...

There's no way that a normal user can change permissions on /dev/null 
unless that user owned it or could write to /dev, period.  /dev/null 
should be a character device file, mode 666, on almost all systems.  
Obviously, if you run lynx as root, or you have super-user access,
you can do whatever you want to /dev/null, and your system will then
probably begin to act quite mysteriously (it's happened to me before,
some weird installation program [running as root] went berzerk).

The major/minor on /dev vary from OS to OS.  For example:

BSDI BSD/OS 2.0.1:
crw-rw-rw-  1 root  wheel   2, 0, 2 Jun 27 09:21 /dev/null

HP-UX A.09.05:
crw-rw-rw-   1 root     root       3 0x000002 Jun 27 08:55 /dev/null

SunOS 5.5.1 (Solaris 2.5.1) [has links in /dev and device files in /devices]:
lrwxrwxrwx   1 root     root          27 Oct  7  1996 /dev/null -> 
../devices/pseudo/address@hidden:null
crw-rw-rw-   1 root     sys       13,  2 Jun 27 09:23 
/devices/pseudo/address@hidden:null

Linux:
crw-rw-rw-   1 root     root       1,   3 Dec 31  1979 /dev/null

SCO Unix 3.2v4.2:
crw-rw-rw-   1 root     sys        4,  2 Jun 27 09:26 /dev/null

Read the manual page for mknod (the command, not the system call) 
for more info on how these are created.

Now, then, it shouldn't be possible for anyone to gain any access
via lynx that they couldn't gain via a normal shell (running as
whatever user lynx runs as).  Does that mean that this hole (which
allows people to run arbitrary programs including /bin/sh as the
user that lynx runs as) can't _lead_ to root access?  No; the attacker 
can use lynx to gain a shell at which point exploiting anything else 
wrong with the system becomes much more possible than it was when 
they could just look at web pages.

I think Fote's mod solves the problem; it would probably be worthwhile 
to check elsewhere for other possible buffer overruns.  With 8-bit 
text and the like these days, it might be possible to put binary 
code in some file out on the web that could overflow a buffer in 
lynx leading to a stack-smashing approach to get to the same results 
as the LYNXDOWNLOAD problem (i.e. users can run arbitrary programs 
from lynx without regard to -restrictions).

Hope this helps, sorry if it's already been discussed or if I'm
missing something.  This issue seems to me to only be a problem
for people wishing to run lynx in a captive environment.


--jss.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;