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 attachment 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.