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)