lynx-dev
[Top][All Lists]
Advanced

[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: Thu, 08 May 1997 23:35:11 EST

Sorry in advance if I'm being too verbose.  I've tried to edit it as
much as possible.

Klaus (Klasu, whatever :-) writes:
 ] On Thu, 8 May 1997, Jonathan Sergent wrote:
 ] > Test each directory (temp_space and its parents, up to the filesystem root)
 ] > for the following:
 ] > 
 ] >    Is the directory group-writeable or world-writeable?
 ] >       If not, is the directory owned by the user or by uid 0?
 ] >          If so, the directory is okay.
 ] >          If not, the directory is bad.
 ] > #if !defined(NO_STICKY_DIRECTORIES)
 ] >       If it is writeable by others, is the sticky bit set?
 ] >          If so, the directory is okay (2).
 ] >          If not, the directory is bad.
 ] > #endif
 ] >    If the directory is bad, print an informational error message and exit.
 ]
 ] You forgot to add a note for your "(2)", but here is one:

Yup, thanks.  I obviously meant to say something about it.

 ] Okay for what?
 ] If you mean "for creating another temporary subdir in this dir", then
 ] probably you are right.

Not even then unless we decide we don't care about malicious users 
making Lynx create directories in strange places.  If the directory was 
located somewhere else in the filesystem, lynx could be unwittingly
putting the directory somewhere where the attacker could rename it to
something else and make a new directory with more symlinks (this time
for files).  It could check after the fact to see if it did this, but
that seems like a hack, and little consolation if the new directory
causes problems (I can't think of any, but there surely must be some).

 ] If you mean "for direct use as temp_space", then it is not okay, since the
 ] sticky bit will not prevent writing to existing files owned by others
 ] including symlinks, AFAIK.

(2) is only true if we're looking at one of the parents of temp_space, 
not temp_space itself.  The whole sticky directory business only applies 
for parents of temp_space.  Lynx can't create directories unless it has 
something like "mkstempdir" which doesn't (as far as I know) exist... 
I'm ignorant in this area.  What would it return?  I'll have to look at 
libc source to understand how mkstemp avoids the race for normal files.

If the directory is world-writeable, lynx can't create anything in
it securely without something like mkstemp.

If it's group-writeable, the same applies unless there's only one 
person in the group.  This is important for sites where each user 
is in his own group and umask is set to 0007.

If it's neither world-writeable nor group-writeable, or if it is
group-writeable by a group with only one member but not world-writeable,
then if lynx can create anything in the directory, it can do so without 
risk.

How's that?

I still think temp_space == "~" is better, but people are bound to
set it to /tmp if it fills up their disk quota.  People here did this
with caches from other browsers and then proceeded to set their cache
limits ridiculously high and fill up / on an HP-UX 9.x cluster with a 
shared root filesystem between cnodes and no separate /tmp.  That 
setup is obviously problematic, but still...

Oh, one other thing... can anyone come up with a list of platforms
in the Makefile which don't support sticky directories?

Are there any platforms where one can overwrite a file with mkdir()?


--jss.
;
; 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]