Dave Camp at Critical Path Software discovered a buffer overflow in CUPS. According to upstream: "The issue was exploitable by users with the ability to configure CUPS and may result in the execution of arbitrary commands with the privileges of cupsd."
Created attachment 280381 [details] Proposed upstream patch
Tim, I'll admit I have no idea how this is exploited, but it doesn't sound like it's a terribly useful flaw. Your input would be most appreciated here.
opengrok didn't actually find the vulnerable code in any shipped version of cups, but did find it in these support packages (I've not checked if any of these actually are compiled/used). /RHEL-2.1/ghostscript-6.51-16.3.src.rpm/ghostscript-6.51/print-4.0.5/cups/ /RHEL-3/gimp-print-4.2.4-5.1.src.rpm/gimp-print-4.2.4/src/cups/ /RHEL-4/gimp-print-4.2.7-2.src.rpm/gimp-print-4.2.7/src/cups/ /RHEL-5/gimp-print-4.2.7-22.src.rpm/gimp-print-4.2.7/src/cups/
So it seems the flaw in question here is that if a user can configure the CUPS server, they could set a username in the printer URL that is too long and will overflow a stack buffer. This could potentially allow someone with access to configure cups to execute code as the cupsd user. The issue is that if a user already has this sort of rights, can they cause cupsd to execute arbitrary commands?
Yes, that is exactly right. If a user has the ability to change the URI associated with a queue, or create a new queue, they can cause the backend to overflow its username buffer. Some backends run as root: ipp, lpd and serial. So constructing a URI for one of these root-priv backends could allow an attacker to execute arbitrary commands as user root. RHEL-4 (1.1.22-0.rc1.9.20.2.el4_5.2) and RHEL-3 (1.1.17-13.3.46) are both vulnerable to this. The other callers of httpSeparate() that Mark found (opengrok looks like a really useful tool) seem to be okay: /RHEL-2.1/ghostscript-6.51-16.3.src.rpm/ghostscript-6.51/print-4.0.5/cups/ canon.c not present epson.c allocates sufficient storage for username (1024 bytes) epson.c has no dangerous optptr loop /RHEL-3/gimp-print-4.2.4-5.1.src.rpm/gimp-print-4.2.4/src/cups/ canon.c allocates sufficient storage for username (1024 bytes) canon.c has no dangerous optptr loop epson.c allocates sufficient storage for username (1024 bytes) epson.c has no dangerous optptr loop /RHEL-4/gimp-print-4.2.7-2.src.rpm/gimp-print-4.2.7/src/cups/ canon.c allocates sufficient storage for username (1024 bytes) canon.c has no dangerous optptr loop epson.c allocates sufficient storage for username (1024 bytes) epson.c has no dangerous optptr loop /RHEL-5/gimp-print-4.2.7-22.src.rpm/gimp-print-4.2.7/src/cups/: canon.c allocates sufficient storage for username (1024 bytes) canon.c has no dangerous optptr loop epson.c allocates sufficient storage for username (1024 bytes) epson.c has no dangerous optptr loop
And just to clarify: RHEL-5 is not vulnerable to this.
This issue is not a security flaw. It's completely harmless, here is why: The variables in question are the following: char method[255], /* Method in URI */ hostname[1024], /* Hostname */ username[255], /* Username info */ resource[1024], /* Resource info (printer name) */ filename[1024]; /* File to print */ The issue is that the rest of the program thinks that username is 1024 bytes, not 255. This means that at most, username will write 769 too many characters. Those characters don't go anywhere dangerous if there isn't any stack reordering going on (which there isn't for RHEL 3 and 4). They will overflow into hostname, which is then filled in after username is, which means that this won't even crash. The patch also contains this bit: options ++; - for (ptr = value; *options && *options != '+';) + for (ptr = value; *options && *options != '+'; options++) if (ptr < (value + sizeof(value) - 1)) - *ptr++ = *options++; + *ptr++ = *options; *ptr = '\0'; Upstream tells me that this patch fixes a possible flaw where a very long command line could cause the backend handler to enter an infinite loop. It seems that this is only possible for an admin to cause, which does not cross a trust boundary, and not a security flaw. I am changing the impact to none.
issue is public, opening bug
Only CUPS versions prior to 1.2.0 were affected by this issue. As described in comment #11, this issue is not exploitable on Red Hat Enterprise Linux 3 and 4. Red Hat Enterprise Linux 5 and current Fedora versions ship CUPS packages not affected by this problem.