Re: regarding the (ex)preserve holes

[newsham () wiliki eng hawaii edu (Timothy Newsham)]

> Matthew Harding wrote:
> > How does one go about determining the dangerousness of the (ex)preserve
> > holes? I notice on my SunOS 4.1.x systems that both expreserve and 
> > exrecover are suid root, but I assume that the latest versions of either
> > the editors or the OS ignore this when playing with the IFS variables.
> > Please tell me this is a correct assumption! I'm not sure if our
> > friends at 8lgm etc. have a script for this, but I'm curious as to the
> > ongoing danger of these holes.
>
> I know that the unpatched Sun 4.1.? version of expreserve also suffered
> from a race condition where you could trick it into writing it's
> tempfile onto a symlink to a root owned file.  The patch number is
> 101579-01 (It's on the Solaris 1.1.1 Recommended Patches list.)

It was worse than a race condition.  There was no race.  The
program tested for the incorrect filename.  Instead of looking
for /usr/preserve/<file> it looked for /<file> and if it didnt
exist (which it never did) it opened the file (this time the
correct one) and started writing to it.  So you didnt have to
worry about winning a race, you just put your file in place
and then have expreserve run.  It seemed that different versions
did different things after this point.  4.1.1 would write the
file as root and leave it.  4.1.3 would write the file as root
and then chown it to the user.

> Some of the free UNIX OSs (FreeBSD and NetBSD) as recently as like a 
> year ago still had a setuid expreserve that called system(3) to 
> send notification mail.  (They have since switched to nvi, which 
> has a far superior method of handling editor preserves).

I know linux was like this.  The elvis preserve program in particular
(so I guess this is a problem from gnu?) would run the program
"mail" with no path specified.  It probably ran it with system()
(strings showed "mail %s").  This was very easy to attack.  

>  -- William McVey
>     Instructional Labs Administrator
>     Purdue Universtiy CS Dept.