5263627 2000-07-10 10:37 /111 rader/ Postmaster Mottagare: Bugtraq (import) <11663> Ärende: LPRng lpd should not be SETUID root ------------------------------------------------------------ Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <200007092318.QAA21788@h4.private> Date: Sun, 9 Jul 2000 16:18:42 -0700 Reply-To: papowell@ASTART.COM Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM> From: Patrick Powell <papowell@ASTART.COM> X-cc: lprng@lprng.com To: BUGTRAQ@SECURITYFOCUS.COM Well, even in spite of all of my efforts, care, and paranoia, I finally dropped the hammer on my foot. Luckily it appears that I spotted this loophole before somebody on the LPRng mailing list did. Or worse yet, got a call from CERT about this problem :-) SUMMARY: Versions of LPRng-3.6.1-LPRng-3.6.15 installed the 'lpd' program 'SETUID root' by default. The lpd executable should be OWNED by root, but not SETUID root. If lpd is SETUID root and executable by users, it is possible for users to append lpd trace and logging messages to existing files owned by the user/group the lpd process runs as. FIX: Remove SETUID permissions from 'lpd' chown root /usr/sbin/lpd chmod 555 /usr/sbin/lpd OR chmod 500 /usr/sbin/lpd ANALYSIS: The problem was discovered when Lars Kellogg-Stedman <lars@larsshack.org> asked why the 'lpd -L logfile' option required logfile to exist. This caused me to look at the code that lpd used to open the log file and I realized that: if the lpd server is not running AND if lpd is installed SETUID root AND if non-root users can execute lpd AND lpd is started using 'lpd -L /path' AND the /path file exists AND the /path file has permissions allowing the user/group the lpd runs as to open the file THEN: lpd will append error and trace messages to /path LPRng-3.6.1 - LPRng-3.6.15 installed LPD setuid ROOT. This appears to be, as they say, a dumb move. The current release (LPRng 3.6.20) installs it non-setuid. The reason for the SETUID root installation appears to be a typeo introduced in the LPRng-3.6.1 Makefile when I was fixing up the install code to install the lpr, lpc, lprm and lpq programs optionally SETUID root or as normal processes. It appears that I installed the 'lpd' program the same way. This was in spite of my notes that "lpd should not be installed setuid ROOT". When the Linux SETUID problem was announced on June 8 I looked at LPRng and made sure that it did not have similar problems. I did an analysis of LPRng and discovered the SETUID install during testing. I removed the SETUID install on the grounds that one less possible compromise was a good idea. This was done in the LPRng-3.6.16 released. The LPD process is usually started up at system initialization time. But there is a simple attack that kills off a surprisingly large number of servers. a) You start a large number of processes, each of which allocates and modifies a large amounts of memory. See the getrlimit(2) and limits(1) for the limits usually imposed on processes. You can exhaust the swap area using this method on most systems. b) You now start sending requests to the server, i.e.- lpd. If the lpd process has not allocated enough memory to hold the pending requests information, then it will do a malloc(). This malloc() will fail due to brk(2) failing with: [ENOMEM] Insufficient space existed in the swap area to support the expansion, and this is a fatal error for the lpd process. Finally, lets look at the files we can modify. The last set of conditions mean that the only files that lpd can modify are the ones owner daemon/group daemon, and that have write permissions for user daemon/group daemon. This, unfortunately, includes the files in spool queues. So, if the user could find a way to stop the running lpd server, then they could append trace information into these files. COMMENTARY: I would really like to see capability based permissions in UNIX and other systems. All that 'lpd' needs is the ability to open and bind to a 'reserved' port, i.e. 515 for listening, and open and bind to a port in the 'reserved' range for outgoing connections. Patrick Powell Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.astart.com) (5263627) ------------------------------------------(Ombruten) 5265580 2000-07-10 22:25 /48 rader/ Postmaster Mottagare: Bugtraq (import) <11679> Ärende: Re: LPRng lpd should not be SETUID root ------------------------------------------------------------ Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM X-OS: FreeBSD 4.0-STABLE X-Sender: cy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200007101617.JAA01760@passer.osg.gov.bc.ca> Date: Mon, 10 Jul 2000 09:17:09 -0700 Reply-To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM> From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> X-To: papowell@ASTART.COM To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: Your message of "Sun, 09 Jul 2000 16:18:42 PDT." <200007092318.QAA21788@h4.private> In message <200007092318.QAA21788@h4.private>, Patrick Powell writes: > Well, even in spite of all of my efforts, care, and paranoia, I > finally dropped the hammer on my foot. Luckily it appears that I > spotted this loophole before somebody on the LPRng mailing list did. Of course anyone who wishes to use LPRng in a mode where it is 100% compatible with lpr/lpd, would need to give up this feature in order to plug this hole. I would think that the bug itself needs to be fixed too. > COMMENTARY: > > I would really like to see capability based permissions in UNIX > and other systems. All that 'lpd' needs is the ability to open > and bind to a 'reserved' port, i.e. 515 for listening, and open > and bind to a port in the 'reserved' range for outgoing connections. If print services would actually listen to port 1515 (example) then the following IP Filter NAT rule could be used to redirect packets to that port thereby allowing print services to not run as root. Sort of a poor man's approach to capabilities until they're implemented on all operating systems. rdr xl0 0/0 port 515 -> 127.0.0.1 port 1515 tcp Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC (5265580) ------------------------------------------(Ombruten)