Bugzilla Bug 74479

Advisory from securesoftware@list.cr.yp.to:

Date: 15 Dec 2004 08:30:45 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: [local] [kill] CUPS 1.1.22 lppasswd ignores write errors, etc.
To: securesoftware@list.cr.yp.to, cups@easysw.com
X-HELOcheck: OK: FQDN
Mailing-List: contact securesoftware-help@list.cr.yp.to; run by ezmlm
Mail-Followup-To: securesoftware@list.cr.yp.to, cups@easysw.com
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.

[-- Attachment #1 [details] --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.3K --]

Bartlomiej Sieka, a student in my Fall 2004 UNIX Security Holes course,
has discovered several security problems in how lppasswd, version 1.1.22
(current), edits /usr/local/etc/cups/passwd. I'm publishing this notice,
but all the discovery credits should be assigned to Sieka.

First, lppasswd blithely ignores write errors in fputs(line,outfile) at
lines 311 and 315 of lppasswd.c, and in fprintf(...) at line 346. An
attacker who fills up the disk at the right moment can arrange for
/usr/local/etc/cups/passwd to be truncated.

Second, if lppasswd bumps into a file-size resource limit while writing
passwd.new, it leaves passwd.new in place, disabling all subsequent
invocations of lppasswd. Any local user can thus disable lppasswd by
running the attached program 63.c.

Third, line 306 of lppasswd.c prints an error message to stderr but
does not exit. This is not a problem on systems that ensure that file
descriptors 0, 1, and 2 are open for setuid programs, but it is a
problem on other systems; lppasswd does not check that passwd.new is
different from stderr, so it ends up writing a user-controlled error
message to passwd if the user closes file descriptor 2.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Created an attachment (id=46031) [details]
63.c from advisory

First claim is highly unlikely.
Second claim is a little thin (Local lppasswd DoS ?) but probably real
Third claim is not valid on Linux, is it ?

Strike that, Linux is perfectly vulnerable to third claim.

CUPS Bugs:

http://www.cups.org/str.php?L1023
http://www.cups.org/str.php?L1024

"Fix Version:	1.1.23rc1"

__

http://secunia.com/advisories/13510/
http://securitytracker.com/id?1012566
http://securitytracker.com/id?1012602

1.1.23rc1 is out

printing herd, pls bump or patch the current version

from release notes:

# The hpgltops filter contained two buffer overflows that could potentially allow remote access to the "lp" account (STR #1024)
# The lppasswd command did not protect against file descriptor or ulimit attacks (STR #1023)

____

http://www.cups.org/str.php?L1024

Ariel Berkman, a student in my Fall 2004 UNIX Security Holes course, has
discovered a remotely exploitable security hole in CUPS. I'm publishing
this notice, but all the discovery credits should be assigned to
Berkman.

A CUPS installation is at risk whenever it prints an HPGL file obtained
from email (or a web page or any other source that could be controlled
by an attacker). You are at risk if you print data through a CUPS
installation at risk. The source of the HPGL file has complete control
over the CUPS ``lp'' account; in particular, he can read and modify the
files you are printing.

Proof of concept: On an x86 computer running FreeBSD 4.10, as root, type

   cd /usr/ports/print/cups
   make install

to download and compile the CUPS package, version 1.1.22 (current).
Then, as any user, save the file 21.hpgl.gz attached to this message,
and type

   gunzip 21.hpgl
   /usr/local/libexec/cups/filter/hpgltops \
   15 $USER test-title 1 none 21.hpgl > 21.ps

with the unauthorized result that a file named x is removed from the
current directory. (I tested this with a 541-byte environment, as
reported by printenv | wc -c.)

Here's the bug: In hpgl-input.c, ParseCommand() reads any number of
bytes into a 262144-byte buf[] array.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

======================================================
Candidate: CAN-2004-1267
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1267
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/cups.txt

Buffer overflow in the ParseCommand function in hpgl-input.c in the
hpgltops program for CUPS 1.1.22 allows remote attackers to execute
arbitrary code via a crafted HPGL file.
======================================================
Candidate: CAN-2004-1268
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1268
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/cups2.txt

lppasswd in CUPS 1.1.22 ignores write errors when modifying the CUPS
passwd file, which allows local users to corrupt the file by filling
the associated file system and triggering the write errors.
======================================================

And a few more :

======================================================
Candidate: CAN-2004-1269
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1269
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/cups2.txt

lppasswd in CUPS 1.1.22 does not remove the passwd.new file if it
encounters a file-size resource limit while writing to passwd.new,
which causes subsequent invocations of lppasswd to fail.
======================================================
Candidate: CAN-2004-1270
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1270
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/cups2.txt

lppasswd in CUPS 1.1.22, when run in environments that do not ensure
that file descriptors 0, 1, and 2 are open when lppasswd is called,
does not verify that the passwd.new file is different from STDERR,
which allows local users to control output to passwd.new via certain
user input that triggers an error message.
======================================================

printing, pls provide an updated ebuild... this bug has been opened over a week
ago

see also bug 75197 about another vulnerability

sorry for the delay, commited cups-1.1.23_rc1 which has the fixes as x86

Thx Heinrich.

Arches please mark stable.

stable on sparc and amd64

stable on ppc64

stable on ppc

This also fixes :

==============================================
CAN-2004-1125

Buffer overflow in the Gfx::doImage function in Gfx.cc for xpdf 3.00 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via a crafted PDF file that causes the boundaries of a maskColors array to be exceeded.
==============================================

*** Bug 75197 has been marked as a duplicate of this bug. ***

Stable on alpha.

GLSA 200412-25
arm,hppa,mips,ia64,s390 : don't forget to test and mark stable to benefit from GLSA

Stable on mips.