[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Re: ...vulnerability in Lynx...
From: |
Jonathan Sergent |
Subject: |
Re: LYNX-DEV Re: ...vulnerability in Lynx... |
Date: |
Fri, 09 May 1997 13:37:49 -0500 |
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.
;
- Re: LYNX-DEV Re: ...vulnerability in Lynx..., (continued)
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Nelson Henry Eric, 1997/05/09
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Brian Tillman, x8425, 1997/05/09
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Scott McGee (Personal), 1997/05/09
- Re: LYNX-DEV Re: ...vulnerability in Lynx...,
Jonathan Sergent <=
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Scott McGee (Personal), 1997/05/09
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Scott McGee (Personal), 1997/05/09
Re: LYNX-DEV Re: ...vulnerability in Lynx..., Scott McGee (Personal), 1997/05/09