Created attachment 373324 [details] ghostscript backtrace Description of problem: When cups prints a PDF, it passes it at some point through pstoraster which calls gs. I noticed a PDF I was working on caused printing to fail, and it appears that some of the debugging output (which pstoraster turns on) from the gs cups driver can trigger a buffer overflow in the gs debug handling (which uses vsprintf - bad bad bad). I think there are two issues here. One is that somehow gs ended up with MediaType argument without null termination (at least that's how it appears). The other is that ghostscript's print handling code uses (v)sprintf when it should be using (v)snprintf. In fact, ghostscript uses (v)sprintf with an "%s" format modifier over 50 times in the source code, several instances of which are probably unsafe (such as here). Consider the following code from base/gsmisc.c: int errprintf(const gs_memory_t *mem, const char *fmt, ...) { ... char buf[PRINTF_BUF_LENGTH]; ... count = vsprintf(buf, fmt, args); errwrite(mem, buf, count); if (count >= PRINTF_BUF_LENGTH) { count = sprintf(buf, "PANIC: printf exceeded %d bytes. Stack has been corrupted.\n", PRINTF_BUF_LENGTH); errwrite(mem, buf, count); } ... Just marvellous -- ghostscript expects vsprintf to return sanely if it overflows (which it doesn't), and then expects to print a nice panic message. It would be a 5 line patch to fix this so that it uses vsnprintf, and if count+1 exceeds the buffer length then it can print a warning that the message was truncated instead. Same goes for outprintf. I will attach the stack trace from gdb, the cups error log and the PDF which caused the problem. I wasn't sure if this was security-sensitive or not, but I ticked the box just to be on the safe side. With all the sanity checking that gcc adds to (v)sprintf these days, it's probably very hard to exploit. Version-Release number of selected component (if applicable): ghostscript-8.70-1.fc12.i686 How reproducible: No idea - works every time on this PDF though. Steps to Reproduce: 1. Open PDF in evince 2. Print PDF to any printer 3. Wait for message saying "printing failed" or somesuch. Additional info: To attach gdb, I put a 'sleep 20' command in the pstoraster shell script (/usr/lib/cups/filter/pstoraster) just before it executed gs, then I "printed" the PDF, found the sleeping bash process and attached gdb to it.
Created attachment 373325 [details] cups error log
Created attachment 373326 [details] PDF which can trigger the buffer overflow
Thanks very much for the report. I'd like to try to catch the "bad MediaType" problem as well as the ghostscript vsprintf problem. Please attach: 1. the PPD for the queue (from /etc/cups/ppd/), and 2. the /etc/cups/printers.conf file
Created attachment 373445 [details] cups printers.conf (usernames+passwords have been removed from this file)
Created attachment 373446 [details] HP Laserjet 6L PPD
OK, both problems found now, thanks.
Created attachment 373495 [details] ghostscript-vsnprintf.patch This is the patch for the more general problem that the errprintf and outprintf functions use the unsafe vsprintf function instead of vsnprintf, leading to an overflow if '%s' is used with an unterminated string. (The dprintf2 macro uses errprintf.)
This affects all versions of Fedora.
This issue does not affect Red Hat Enterprise Linux due it using the older versions of ghostscript. The incorrect debug logging code in gdevcups.c is not present in ghostscript 8.15 and earlier; it was introduced in version 8.64. Likewise, in order to exploit this the MediaType string needs to be larger than the 1024-byte buffer in errprintf, but in older versions of ghostscript, gdevcups does not write out the MediaType string in its debug logging at all. There are also no other calls to errprint or outprintf that use the %s specifier with user-supplied strings.
Upstream responded, and it looks like this issue was already noted to them: http://bugs.ghostscript.com/show_bug.cgi?id=690829
This was assigned CVE-2009-4270
ghostscript-8.70-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ghostscript-8.70-2.fc11
ghostscript-8.70-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ghostscript-8.70-2.fc12
Note: This is not a security flaw in Fedora, as the overflow is caught by FORTIFY_SOURCE resulting in a controlled process termination.
ghostscript-8.70-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0327
ghostscript-8.70-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0350
ghostscript-8.70-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-8.70-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.