Date:         Sun, 9 Jul 2000 16:18:42 -0700
From: Patrick Powell <papowell@ASTART.COM>
Subject:      LPRng lpd should not be SETUID root
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)