Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upA misbehaving client can *crush* the scheduler #3200
Comments
|
CUPS.org User: opher Note 2: It seems that when the server is running in LogLevel debug2 the client successfully reads the whole response. (So no abrupt exit). |
|
CUPS.org User: mike Please duplicate this against the current stable (1.3.10) release from cups.org (and not the patched up versions you get from Red Hat...) There are log messages that are not from the standard CUPS release. If you can't reproduce with the cups.org release, we'll have to close this bug and you'll need to file a bug with Red Hat. |
|
CUPS.org User: mike We are unable to resolve this problem with the information provided. If you discover new information, please file a new STR referencing this one. |
|
CUPS.org User: mike Bringing this back from the dead since we finally have reproduction by Red Hat with a potential patch. From Jan Lieskovsky: Hello vendors, pretty long time ago Opher reported CUPS DoS (cupsd crash), [1] http://www.cups.org/str.php?L3200 We further investigated the issue (reproduced) and Tim Waugh CVE identifier of CVE-2009-3553 has been already assigned While the issue is meta-public, original ticket [1] suggests Embargo date has been set up to Wednesday, 2009-11-18, Thanks && Regards, Jan.Jan iankko Lieskovsky / Red Hat Security Response Team CUPS background:The Common UNIX® Printing System (CUPS) provides a portable CVE-2009-3553 flaw:A pointer use-after-free flaw was found in the way CUPS Flaw analysis (by Tim Waugh):The CUPS scheduler uses an abstracted interface to handle select(),
The cupsdDoSelect() function uses whichever system method is best to
Unfortunately this reference counting is not sufficient to prevent In main.c, cupsdDoSelect() is used to handle client connections and the If cupsdDoSelect() enters an iteration of its file descriptor loop A suggested fix for this is to avoid calling the write callback if Affected CUPS versions: CUPS-1.3.* <= x <= CUPS-1.4.2 (latest)CVE identifier: CVE-2009-3553 has been assigned to this issueCRD date: Wednesday, 2009-11-18, 12:00 UTC timePoC:Pretty complex - unable to reproduce the issue from Linux client. Java Cups Test Jobs client: http://www.cups.org/strfiles/3200/Client.zip Scenario: Server has 300 active printing jobs. Impact: CUPS-1.3.10 - clean crash (see attached debug && debug2 log). See also "raw_steps.txt" and sample textonly.ppd for elaborated list Patches:Attached are patches against 1.3.10 and 1.4.2 versions of CUPS,
diff -up cups-1.4.2/scheduler/select.c.str3200 cups-1.4.2/scheduler/select.c
release_fd(fdptr);
release_fd(fdptr);
Prerequisites:a, Linux host with running cupsd 'serversHostname', 'serversIP' (Selected "Windows x64" platform). CUPS Preparation phase:a, remove all cups related stuff from the system b, download and install cups wget http://ftp.easysw.com/pub/cups/1.3.10/cups-1.3.10-source.tar.gz c, configure cups: modify cups to listen on 'serversIP' and allow connection from 'clientsIP'vi /usr/local/etc/cups/cupsd.conf LogLevel info | debug | debug2 Only listen for connections from the local machine.Listen localhost:631 Restrict access to the server...Allow From clientsIP Order allow,denyadd text-only printer to /usr/local/etc/cups/printers.confSee attached textonly.ppd, you will need to change the serversHostname DeviceURI ipp://serversHostname/printers/my_printer row, other rows can be kept without change. start cups and check if it recognizes 'test1' printer/etc/init.d/cups start schedule about 300 printing jobshead -1000 /usr/share/dict/words > /tmp/file.txt JAVA client preparation phase:Install the SUN JDK 1.6.0_13 Java on WindowsSet the JAVA_HOME variableset JAVA_HOME=C:\Program Files\Java\jdk1.6.0_13\bin Download the malformed client and extract itwget http://www.cups.org/strfiles/3200/Client.zip Attack scenario:Run the java client with 'serversIP' two timesjava TestCupsGetJobs serversIP (you should see something like: "Requested X bytes; Got: Y bytes. Partial string:" "Connection refused:" (two times should be enough) Now check /var/log/messages for You can also check /usr/local/var/log/cups/error_log for full Printer configuration file for CUPS v1.3.10Info Location DeviceURI ipp://serversHostname/printers/my_printer State Idle StateTime 1243606881 Accepting Yes Shared No JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer |
|
CUPS.org User: mike Fixed in Subversion repository. |
|
"str3200.patch": Index: scheduler/select.c--- scheduler/select.c (revision 8887)
release_fd(fdptr);
|
Version: 1.3.10
CUPS.org User: opher
Hello,
First, I didn't know if this qualifies as a security issue so I didn't mark it. Please feel free to mark it as such if it is.
A client (attached) running on:
Windows XP SP3 (up to date with security fixes)
Sun JDK 1.6.0_13
can crush or hang the CUPS server running on:
Fedora 10 i386 / cups 1:1.3.10-5.fc10
CentOS 5.2 x86_64 / cups 1.3.7-8
The Client is doing a Get-Jobs (like `lpq -a').
The server has 300 active jobs.
The client is broken: it thinks it got an incomplete response, exits abruptly causing the JVM/OS to send a TCP RST.
A .cap file from Wireshark (v1.0.7) running on the client is attached.
At that point CUPS scheduler either:
1. crashes
2. hangs
(rarely it takes a second try to kill the server)
the error_log shows this:
D [15/May/2009:18:06:49 +0300] cupsdAcceptClient: skipping getpeercon()
D [15/May/2009:18:06:49 +0300] cupsdAcceptClient: 1 from 10.236.33.36:631 (IPv4)
D [15/May/2009:18:06:49 +0300] cupsdReadClient: 1 POST / HTTP/1.0
D [15/May/2009:18:06:49 +0300] cupsdAuthorize: No authentication data provided.
D [15/May/2009:18:06:49 +0300] cupsdIsAuthorized: username=""
D [15/May/2009:18:06:49 +0300] Get-Jobs ipp://localhost/
D [15/May/2009:18:06:49 +0300] cupsdProcessIPPRequest: 1 status_code=0 (successful-ok)
D [15/May/2009:18:06:49 +0300] cupsdCloseClient: 1
D [15/May/2009:18:06:49 +0300] cupsdCloseClient: 7803248
To reproduce:
(replace 10.236.33.136 with your server address)
Note: I tried running the Client on a Linux machine but couldn't crash the CUPS server. I'm not sure but it seems that the JVM/Linux sent a TCP FIN (and not a TCP RST as on the MS-Windows machine).
Regards,
Opher.