Bugtraq 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----- 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 =====================
Current thread:
- Security problems on SCO's lp subsystem Marco Paganini (Jun 18)
- Re: Security problems on SCO's lp subsystem Michael L. Wilkerson Jr. (Jun 18)
- Word 98 Insecurity Mike (Jun 19)
- <Possible follow-ups>
- Re: Security problems on SCO's lp subsystem Bela Lubkin (Jun 19)
- Re: Security problems on SCO's lp subsystem Bela Lubkin (Jun 19)