[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<
- Re: lynx-dev 2.8.1dev.19.patch.gz, (continued)
- Re: lynx-dev 2.8.1dev.19.patch.gz, T.E.Dickey, 1998/08/03
- Re: lynx-dev 2.8.1dev.19.patch.gz, Bela Lubkin, 1998/08/03
- Re: lynx-dev 2.8.1dev.19.patch.gz, Bela Lubkin, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz,
Bela Lubkin <=
- Re: lynx-dev 2.8.1dev.19.patch.gz, T.E.Dickey, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz, T.E.Dickey, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz, T.E.Dickey, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz, Bela Lubkin, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz, Bela Lubkin, 1998/08/04
- Re: lynx-dev 2.8.1dev.19.patch.gz, T.E.Dickey, 1998/08/05
- Re: lynx-dev 2.8.1dev.19.patch.gz, Nelson Henry Eric, 1998/08/11