[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Scott McGee (Personal)
Subject: Re: LYNX-DEV Re: ...vulnerability in Lynx...
Date: Fri, 9 May 1997 14:16:45 -0600


If a system is set up with a "sticky" temp directory, and lynx creates a
subdirectory there with resonable permissions, can it use the current method
of creating temp files without becoming a tool for hackers to compromise

If so, then all we need to do is to make lynx create and use said subdirectory
(with a wrapper script, or a code change) and we have sufficiently addressed
the security problem for now. We could contact CERT, inform them of the 
problem with non-sticky temp dirs, the further problem with some software
(including lynx) despite sticky dirs, workarounds for older (2.5 and later)
versions of Lynx, and the fix for lynx (a new version).

In this case, despite all the other issues, making lynx use a safe subdir
on a system with a safe tempfile is a good fix. Further modification to
Lynx to improve saftey on such systems, or on systems without a safe temp
dir are seperate issues that don't have to be dealt with.

We are not responsible for systems with unsafe temp dirs. Being resonable
people, we should consider making lynx as safe as possibly for such systems,
but the reality is, they need to fix the inherant safety issues on the system
or other programs will also offer problems.

If and only if Lynx is inherently a security risk on an otherwise secure 
system do we need to exhibit this level of concern. It would seem that at
the moment Lynx is in this situation, but if a simple subdir will change
that, then the use of such a subdir is all that should be needed to address
the current security problem.

Making Lynx refuse to run on a system with inherant security problems, is,
IMHO rather stupid. The system may be perfectly secure due to its environment
(I've heard of systems used by the military where software and OS security
risks were ignorable because the system was completely isolated and access
to it was securely maintained. So what if Lynx would let a hacker fool with
such a system, the hacker would never get access to it), or the admin of
the system may have decided he/she doesn't care about the risk enough to
worry (I have a PC beside me that would meet both these conditions. If it
was running Linux, and was unsecure this way, I really wouldn't care, as
long as Lynx worked anyway.) In either case, refusing to run is a silly
option and just plain stupid if not configurable. Lynx isn't a tool to help
provide, monitor, or maintain system security, it is a web browser.

Do NOT get me wrong here, I am in favor of changing Lynx to use mkstemp()
and passing open file handles instead of names of closed files because it
_does_ make lynx more secure. What I object to is schemes that will make
lynx refuse to run on systems where security is beyond lynx's ability to
control, or trying to rush such major changes through to fix a problem that
can be addressed more simply on systems with reasonable security in place.

If I post my system's root password on the internet, nothing lynx can do,
including refusal to run, will help my system be any more secure. That isn't
lynx's job anyway. Lynx shouldn't compromise security if I attempt to maintain
it, but it shouldn't refuse to run if I decide to ignore security.


Scott McGee: Salt Lake Community College Webmaster | When in danger,
___________________________________________________| or in doubt,
Email: address@hidden (Scott McGee)         | run in circles,
Web: | scream and shout.
My opinions do not necessarily reflect those of the College. Trust me!
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]