L0pht Security Advisory

        Advisory Name: Quadruple Inverted Backflip
    Advisory Released: 1/8/00
          Application: LPD on RedHat Linux 4.x, 5.x, 6.x
             Severity: A remote user can execute arbitrary code on a properly
                   configured Linux LPD server.
               Status: Vendor contacted, fixes available.
               Author: dildog@l0pht.com
                  WWW: http://www.l0pht.com/advisories.html

Overview:

  As suggested by the name, this is a relatively complex vulnerability
to exploit, but it can be done. The problem lies in the fact that although
SNI (now NAI) found a whole bunch of problems in BSD LPD two years ago, for
some unknown reason, the majority of these problems still affect Linux LPD.
It's harder to exploit now, but it's still possible. The exploit allows any
user who can print to an LPD server to gain 'bin' user and 'root' group access
to the system remotely.

Description:

  The problems being exploited here are four-fold.

1. LPD allows remote machines to print files without having access to LPD,
   because LPD compares the reversed-resolved peer name of the accepted
   socket's address, with the gethostname() name returned by the machine, and
   if they're the same, grants access without question. Hence, if you're the
   master of your own DNS, simply make your IP address reverse-resolve to the
   same hostname as the LPD server, and you have access to it.

2. LPD allows you to send as many data files to the printer spooler directory
   as you want. These files can be binaries, text, or otherwise.

3. LPD allows you to specify anything you want in the 'control file' (often
   named cfBLAHBLAHBLAHBLAH in /var/spool/lpd/<printer>/ ), even host names
   and other things that don't exist.

4. LPD allows you to specify an argument to /usr/sbin/sendmail and execute it.
   this is done by specifying that LPD should send mail back to the print job
   owner when the print job is completed ('M' in the cf file). However, the
   sendmail argument in the LPD cf file doesn't have to be an email address,
   it can be a sendmail option, such as '-C<alternateconfigfilepath>'.

So, we have the unfortunate result that one can send several data files to
print, including a disguised sendmail configuration file, after which a cf
file is sent along, requesting that sendmail be invoked with the configuration
file that is sent over.

Quick solution:
  
  Download the fix from RedHat at:

Red Hat Linux 6.x:

Intel:
  ftp://updates.redhat.com/6.1/i386/lpr-0.48-1.i386.rpm

Alpha:
  ftp://updates.redhat.com/6.1/alpha/lpr-0.48-1.alpha.rpm

Sparc:
  ftp://updates.redhat.com/6.1/sparc/lpr-0.48-1.sparc.rpm

Source packages:
  ftp://updates.redhat.com/6.1/SRPMS/lpr-0.48-1.src.rpm


Red Hat Linux 5.x:

Intel:
  ftp://updates.redhat.com/5.2/i386/lpr-0.48-0.5.2.i386.rpm

Alpha:
  ftp://updates.redhat.com/5.2/alpha/lpr-0.48-0.5.2.alpha.rpm

Sparc:
  ftp://updates.redhat.com/5.2/sparc/lpr-0.48-0.5.2.sparc.rpm

Source packages:
  ftp://updates.redhat.com/5.2/SRPMS/lpr-0.48-0.5.2.src.rpm


Red Hat Linux 4.x:

Intel:
  ftp://updates.redhat.com/4.2/i386/lpr-0.48-0.4.2.i386.rpm

Alpha:
  ftp://updates.redhat.com/4.2/alpha/lpr-0.48-0.4.2.alpha.rpm

Sparc:
  ftp://updates.redhat.com/4.2/sparc/lpr-0.48-0.4.2.sparc.rpm

Source packages:
  ftp://updates.redhat.com/4.2/SRPMS/lpr-0.48-0.4.2.src.rpm


  Or, disable LPD cuz something tells me there's a bunch of other
problems in there too. Someone needs to audit that thing. There ain't no quick
fix for this one.



Exploit:

  http://www3.l0pht.com/~dildog/qib.tgz
  Read the README that's in there.

  That's all folks.

dildog@l0pht.com

  [ For more advisories check out http://www.l0pht.com/advisories.html ]