lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev 2.8.1dev.19.patch.gz


From: Bela Lubkin
Subject: Re: lynx-dev 2.8.1dev.19.patch.gz
Date: Mon, 3 Aug 1998 12:31:34 -0700

T.E.Dickey wrote:

> > T.E.Dickey wrote: 
> >  
> > > 1998-07-31 (2.8.1dev.19) 
> >  
> > Briefly, for the impatient: dev.19 re-introduces serious /tmp security 
> > holes -- don't use it unless you are using per-user Lynx temp dirs. 
> no -- read below (perhaps I was too terse in my changelog entry, but the
> information is there).

The changelog alerted me, but my comments were based on the code itself.

> > > * modify OpenHiddenFile so that it can overwrite files owned by the real 
> > >   user if the O_EXCL open fails because the file already exists - TD 
> >  
> > This modification reintroduces temp file problems!  Part of the point of 
> > opening with O_CREAT | O_EXCL is that this combination does not follow 
> > symbolic links.  If you strictly use O_CREAT | O_EXCL (and other related 
> no - read the code -- I'm pretty sure it's ok.  I check that it is owned

I did.

> by the real user before deciding to reopen it.  If you don't allow this,
> you cannot overwrite a screen printfile. (As an afterthought, I should
> add a line to verify that it's a file, not a directory).

I'm afraid you just can't do such checks.  They inevitably lead to race
conditions and security holes.  You *have* to do your final open with
O_CREAT | O_EXCL.

An option to prevent the problem you're trying to prevent:

  if open(O_CREAT | O_EXCL) fails EEXIST,
    use stat() to learn owner and type of the file
    if it's us (and it's a normal file), unlink(file)
    if open(O_CREAT | O_EXCL) fails EEXIST again,
      we don't understand what's going on, cancel operation

> > precautions, and are generally very careful), it is safe to use a public 
> > /tmp directory as long as the directory is "sticky" (doesn't allow users 
> > to delete other users' files). 
> >  
> > The new code takes that away again.  I can create a symlink to one of 
> > your files.  The first open(O_CREAT | O_EXCL) will fail with EEXIST, so 
> but you can't open it with lynx - since you don't own it.  (even if lynx
> were running setuid as root).

You're responding to the wrong situation.

I am an attacker.  *You* are running Lynx.  I anticipate that you're
going to create a temp file named /tmp/L1234-0TMP.html.  I do:

  ln -s /home/dickey/.profile /tmp/L1234-0TMP.html

Your first open fails (EEXIST).  So you stat the file, find that it
*does* belong to you (stat returns info about the target of the symlink),
so you truncate your .profile.

> > you'll go into the new code and truncate the file. 
> >  
> > Suppose I know root's about to run Lynx.  I can anticipate one of the 
> > temp filenames it's going to use, and do: 
> >  
> >   ln -s /.rhosts /tmp/$ANTICIPATED_NAME 
> root isn't the real owner of the file (I just retested that it will not
> be able to write the file)

I don't know where you're testing or what scenario you tried.  The above
*does* work.  I just tried it.  root *is* the real owner of the target
of the symlink, which is what you're testing for.

>Bela<

reply via email to

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