COMMAND

    lp

SYSTEMS AFFECTED

    SCO 5.0.2 (Enterprise), 5.0.4

PROBLEM

    Marco Paganini found following.  Normal users with lp access  (the
    default) may cause headaches to the system administrador.

    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.

        $ 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.

    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.  Older
    versions of SCO may exhibit this problem, since many of these have
    /usr/bin/lp setuid to root.  To summarize:

      1. Berkeley `lp` client doesn't give up setuid/setgid privileges
         when removing a file according to "-R" flag.
      2. Berkeley  `lp` client  passes on  setuid/setgid privileges to
         SysV `lp` client, when a Berkeley lpd destination hasn't been
         specified.
      3. SysV  `lp` client  doesn't give  up setuid/setgid  privileges
         before opening target file for "-L live=file" flag.
      4. "-L live=file" flag appears to be archaic, perhaps  shouldn't
         exist at all?

SOLUTION

    SCO  OpenServer  includes  two  spooling  subsystems: the System V
    spooler and  the Berkeley  spooler.   Berkeley spooler  support is
    split  into  client  and  server  support.   By default, only SysV
    client support is active.  Berkeley client support is activated by
    root running `mkdev rlp`;  or through `scoadmin printer  manager`.
    Activating  Berkeley  client  support  causes  certain binaries to
    change; for instance, /usr/bin/lp changes from:

        ---x--s--x   1 bin      lp         91044 Dec 16  1997 /usr/bin/lp

    to:

        ---x--x--x   1 bin      lp          2472 Jun 19 11:09 /usr/bin/lp

    Exact  dates  and  sizes  will  vary  by  release, but the general
    pattern will be the same.  The Berkeley client version is a simple
    wrapper program which actually execs /usr/lpd/remote/lp:

        -rws--s--x   1 root     daemon     36116 Dec 16  1997 /usr/lpd/remote/lp

    If a Berkeley  client destination hasn't  been specified, that  in
    turn execs the original SysV lp client, which has been saved aside
    in /usr/lpd/local:

        ---x--s--x   1 bin      lp         91044 Jun 19 11:09 /usr/lpd/local/lp

    Also, in general, /etc/printcap will exist if and only if Berkeley
    client support has  ever been activated.   Both of these  exploits
    require Berkeley client support to be active, although the details
    are different  so perhaps-obvious  workaround: do  not enable  the
    Berkeley  lpd  client.   It  should  be  sufficient  to move aside
    /etc/printcap and /usr/spool/lpd, then run `mkdev rlp`, tell it to
    "remove remote printing".  The SysV spooler can do remote printing
    with any available remote command processor (rcmd (nee rsh), etc.)
    which could  be used  to shunt  jobs to  a different  system's lpd
    client.