Re: lpd exploit?

[Olaf Kirch <okir () CALDERA DE>]

> [12:02] <user1> theres an lpd exploit out

Well, maybe true, maybe just rumors...

While I'm not aware of any such exploit, I thought I'd dig up an email
I wrote almost a year ago, concerning security problems in the BSD based
lpd shipped by several Linux vendors.

I don't know whether these holes got fixed; I didn't specifically check
whether these problems were indeed exploitable. The comment that says
"fortunately this memory appears to be malloced" was of course naive ;-)
Working heap overflow exploits have been published since then.

Even if most of the stuff below is academic, some may find it useful...

Cheers,
Olaf
--
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir () monad swb de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir () caldera de    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.
> --- Begin Message ---
>
>
> From: Olaf Kirch <okir () caldera de>
>
> Date: Sat, 12 Feb 2000 12:51:42 +0100
>
> A while ago I sent the following to this list, but haven't heard from
> Redhat or Suse whether this really affects them, and whether they
> intend to fix it.
>
> Olaf
>
> ----- Forwarded message from Olaf Kirch <okir () monad swb de> -----
>
> Date: Mon, 10 Jan 2000 19:25:01 +0100
> From: Olaf Kirch <okir () monad swb de>
> To: vendor-sec () lst de
> Subject: [notting () redhat com: [linux-security] [RHSA-2000:002] New lpr packages available]
>
> I think everybody has seen this by now, but I'm resending this
> because I have some comments.
>
> It looks as if in recvjob, it doesn't check properly whether the
> control file name contains a slash. Around line 167, it creates
> tfname out of the first six characters of the file name provided
> by the client, plus the client's host name. The resulting string
> is checked for slashes. It then reads the file (no size limit, no timeout),
> and if all goes well hard links the file to the client-provided
> path name without further ado.
>
> I also appears as if lpd's readjob() lets you chown arbitrary files.
> When you transmit a cf file, you can specify a login name using `P',
> and a list of files (`a' to `z'). These file names are stored in an
> array without checking for / etc. Upon exit from the function it
> loops over these files and chowns them to the name of the user you
> provided in the P line.
>
> Also note that you can transmit file names up to 1000-odd
> bytes (the buffer used by getline() is BUFSIZ==1024 bytes). OTOH
> the getq function does a simple strcpy of queue file names to
> struct queue.name, which is MAXNAMLEN == NAME_MAX == 255.
> Fortunately at least this memory appears to be malloced.
>
> Also take a look at the rcleanup function. It does this:
>
>         if (dfname && !strchr(dfname, '/')) {
>             do {
>                 do {
>                     unlink(dfname);
>                 } while (dfname[2]-- != 'A');
>                 dfname[2] = 'z';
>             } while (dfname[0]-- != 'd');
>         }
>
> Now if you start with 0vmlinux you'll sooner or later end up
> with unlink(/vmlinuz).
>
> Can you say `Swiss Cheese'?
>
> Olaf
>
> PS:  I've looked at the source for half an hour. I'm sure if
>      you look harder you'll find more buried gems.  I'm so happy we
>      ship lprng.
> PPS: If you issue an advisory please make sure to include ``RedHat
>      thanks Olaf Kirch of Caldera'' :-)
>
>
> ----- Forwarded message from Bill Nottingham <notting () redhat com> -----
>
> Date: Fri, 7 Jan 2000 18:14:49 -0500
> From: Bill Nottingham <notting () redhat com>
> To: redhat-watch-list () redhat com
> Cc: linux-security () redhat com, bugtraq () securityfocus com
> Subject: [linux-security] [RHSA-2000:002] New lpr packages available
>
> ---------------------------------------------------------------------
>                    Red Hat, Inc. Security Advisory
>
> Synopsis:               New lpr packages available
> Advisory ID:            RHSA-2000:002-01
> Issue date:             2000-01-07
> Updated on:             2000-01-07      
> Keywords:               lpr lpd DNS sendmail
> Cross references:       
> ---------------------------------------------------------------------
>
> 1. Topic:
>
> New lpr packages are available to fix two security problems
> in lpd.
>
> 2. Relevant releases/architectures:
>
> Red Hat Linux 4.x, all architectures
> Red Hat Linux 5.x, all architectures
> Red Hat Linux 6.x, all architectures
>
> 3. Problem description:
>
> Two security vulnerabilities exist in the lpd
> (line printer daemon) shipped with the lpr package.
>
> First, authentication was not thorough enough. If a remote user
> was able to control their own DNS so that their IP address resolved
> to the hostname of the print server, access would be granted,
> when it should not be.
>
> Secondly, it was possible in the control file of a print job
> to specify arguments to sendmail. By careful manipulation of
> control and data files, this could cause sendmail to be executed
> with a user-specified configuration file. This could lead
> very easily to a root compromise.
>
> It is recommended that all users of Red Hat Linux using the
> lpr package (which is required to print) upgrade to the
> fixed packages.
>
> Thanks go to DilDog (dildog () l0pht com) for noting the vulnerability.
>
> 4. Solution:
>
> For each RPM for your particular architecture, run:
>     rpm -Fvh <filename>
> where filename is the name of the RPM.
>
> 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla/ for more info):
>
> 6. Obsoleted by:
>
> 7. Conflicts with:
>
> 8. RPMs required:
>
> 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
>
>
> 9. Verification:
>
> MD5 sum                           Package Name
> --------------------------------------------------------------------------
> 78f2220331189e723eab944b53d0710e  i386/lpr-0.48-1.i386.rpm
> 3fcb89eb1a76741a505d3eeeddfa3674  alpha/lpr-0.48-1.alpha.rpm
> 441cfee04428ca215d98d9ce3d20bc4d  sparc/lpr-0.48-1.sparc.rpm
> 55c6a740b03569919ec08992257cad96  SRPMS/lpr-0.48-1.src.rpm
>
> 25ba4d2b49ff42403062d44f52f59947  i386/lpr-0.48-0.5.2.i386.rpm
> aa13284c581601705fef727565ed407e  alpha/lpr-0.48-0.5.2.alpha.rpm
> 8d158ba104fadbfc84b5122f9564b2ed  sparc/lpr-0.48-0.5.2.sparc.rpm
> 3d7a10a086f5bd5aea739ec41d761881  SRPMS/lpr-0.48-0.5.2.src.rpm
>
> a215955554df002e91e336abd310e3f1  i386/lpr-0.48-0.4.2.i386.rpm
> a96363769e3815a5a5bb40084d8fac61  alpha/lpr-0.48-0.4.2.alpha.rpm
> f56271b462851990238a24a5357c454f  sparc/lpr-0.48-0.4.2.sparc.rpm
> 48453e0c888e3d124a6b50fbb9a89be9  SRPMS/lpr-0.48-0.4.2.src.rpm
>
> These packages are GPG signed by Red Hat, Inc. for security.  Our key
> is available at:
>     http://www.redhat.com/corp/contact.html
>
> You can verify each package with the following command:
>     rpm --checksig  <filename>
>
> If you only wish to verify that each package has not been corrupted or
> tampered with, examine only the md5sum with the following command:
>     rpm --checksig --nogpg <filename>
>
> 10. References:
>
> --
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
>
> To unsubscribe:
>   mail -s unsubscribe linux-security-request () redhat com < /dev/null
>
>
> ----- End forwarded message -----
>
> --
> Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
> okir () monad swb de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
> okir () caldera de    +-------------------- Why Not?! -----------------------
>          UNIX, n.: Spanish manufacturer of fire extinguishers.
>
> ----- End forwarded message -----
>
> --
> Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
> okir () monad swb de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
> okir () caldera de    +-------------------- Why Not?! -----------------------
>          UNIX, n.: Spanish manufacturer of fire extinguishers.
>
>
> --- End Message ---