A misbehaving client can *crush* the scheduler #3200
A client (attached) running on:
can crush or hang the CUPS server running on:
The Client is doing a Get-Jobs (like `lpq -a').
At that point CUPS scheduler either:
the error_log shows this:
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).
The text was updated successfully, but these errors were encountered:
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
Bringing this back from the dead since we finally have reproduction by Red Hat with a potential patch. From Jan Lieskovsky:
pretty long time ago Opher reported CUPS DoS (cupsd crash),
CVE identifier of CVE-2009-3553 has been already assigned
While the issue is meta-public, original ticket  suggests
Embargo date has been set up to Wednesday, 2009-11-18,
Thanks && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Response Team
The Common UNIXÂ® Printing System (CUPS) provides a portable
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 issue
CRD date: Wednesday, 2009-11-18, 12:00 UTC time
Pretty complex - unable to reproduce the issue from Linux client.
Java Cups Test Jobs client:
Server has 300 active printing jobs.
CUPS-1.3.10 - clean crash (see attached debug && debug2 log).
See also "raw_steps.txt" and sample textonly.ppd for elaborated list
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
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
c, configure cups:
modify cups to listen on 'serversIP' and allow connection from 'clientsIP'
LogLevel info | debug | debug2
Only listen for connections from the local machine.
Restrict access to the server...Allow From clientsIP Order allow,deny
add text-only printer to /usr/local/etc/cups/printers.conf
See attached textonly.ppd, you will need to change the serversHostname
row, other rows can be kept without change.
start cups and check if it recognizes 'test1' printer
schedule about 300 printing jobs
head -1000 /usr/share/dict/words > /tmp/file.txt
JAVA client preparation phase:
Install the SUN JDK 1.6.0_13 Java on Windows
Set the JAVA_HOME variable
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_13\bin
Download the malformed client and extract it
Run the java client with 'serversIP' two times
java 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
--- scheduler/select.c (revision 8887)