Re: LYNX-DEV Re: ...vulnerability in Lynx...

[Jonathan Sergent]

In message <address@hidden>, Scott McGee (Personal) writes:
 ] Come on now! Lynx isn't some DOD hyper sensitive program with top secret
 ] data that should only be run in a ultra secure environment, it is a web
 ] browser. It should attempt to run in any environment it is asked to. If the
 ] system Lynx is run or compiled on is noticably insecure, then _AT MOST_ it
 ] should issue a polite, ignorable notice, and then continue to run.

... 

The issue here is that it's fairly trivial for a malicious user to make
Lynx overwrite another users' files.  There are ways of fixing Lynx so 
that it will work on a poorly set up system without causing security 
problems.

Due to the way Lynx uses temporary files, there is no "quick fix" to 
this if the temp files are in a location where other users can rename 
or erase them at will.

The question is not a matter of limiting lynx functionality, but improving
it.

If Joe Bloggs has the space to keep cached images from Netscape in his
home directory (which it does by default, but can be configured to
put them in other places), then he certainly has room for Lynx to create 
the occasional temporary file in his directory when he's downloading
something.  If not, the system will tell him he's over quota, and he'll
go free up some space and try again.  If the user cares all that much
about it, he'll take the time to read the documentation and see that he
can make himself a temporary directory somewhere where he has more space
and then set LYNX_TEMP_SPACE.  

"Upgrade to a current version" is a perfectly valid response for concerns
about versions 2.4.x and older.

I think the proper things to do in the long run include:

 -- Make the default for temporary files point to $HOME in future versions,
    but still allow the installer to change it to somewhere else.

 -- Add checks so that Lynx will notify the user if it is storing these files
    somewhere bad (I outlined what I think defines "bad" in a previous post)
    and put a nice long delay in there so it's sufficiently annoying that
    they'll consider fixing it.

 -- Add a compile-time option to userdefs.h which allows the installer to
    specify that lynx should refuse to run if it is storing its temp files
    somewhere insecure.  Turn this on by default?

 -- Work on revamping temp file support in future versions to avoid this 
    problem altogether.  mkstemp is a simple function; we can grab the 
    version from GNU libc and modify it to suit our needs.  The main 
    problem is avoiding opening temp files, closing them, then opening 
    them again; if /tmp is mode 0777, then someone could replace the file 
    with something else in between.  This obviously requires some work, 
    but I think it is not impossible to make a web browser work in this 
    fashion.  When this is done then the above two items can be removed.

Anything less is a temporary hack so that security-conscious administrators
can avoid the problem without having to remove Lynx from their systems.
If there is an advisory of any sort on this issue, I'm sure plenty of them
will unless there is an easy fix, such as:

# If someone types "lynx.real" then it's their own fault! ;-)
mv /usr/local/bin/lynx /usr/local/bin/lynx.real

cat > /usr/local/bin/lynx <<EOF
#!/bin/sh
LYNX_TEMP_SPACE="$HOME"; export LYNX_TEMP_SPACE
exec /usr/local/bin/lynx.real "$@"
EOF

... for versions 2.5 and up.  If the user has a world-writeable home
directory, he has plenty of other problems to worry about.  If it's
a captive account, the admin can and should make a special temp 
directory for it somewhere.

$0.05 this time.


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