Date: Sat, 8 Jan 2000 12:40:51 -0500
From: Dildog <dildog@L0PHT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: L0pht Advisory: LPD, RH 4.x,5.x,6.x
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 ]
