Bug 415141 - (CVE-2007-5848) CVE-2007-5848 CUPS buffer overflow
CVE-2007-5848 CUPS buffer overflow
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=none,source=vendorsec,reported...
: Security
Depends On: 418361 418371 418381
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-06 20:26 EST by Josh Bressers
Modified: 2008-01-09 06:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 06:59:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed upstream patch (4.77 KB, patch)
2007-12-06 20:26 EST, Josh Bressers
no flags Details | Diff

  None (edit)
Description Josh Bressers 2007-12-06 20:26:44 EST
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."
Comment 1 Josh Bressers 2007-12-06 20:26:44 EST
Created attachment 280381 [details]
Proposed upstream patch
Comment 4 Josh Bressers 2007-12-06 20:28:37 EST
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.
Comment 5 Mark J. Cox (Product Security) 2007-12-07 01:28:10 EST
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/
 

Comment 7 Josh Bressers 2007-12-07 16:36:52 EST
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?
Comment 8 Tim Waugh 2007-12-10 11:39:05 EST
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

Comment 9 Tim Waugh 2007-12-10 11:57:39 EST
And just to clarify: RHEL-5 is not vulnerable to this.
Comment 11 Josh Bressers 2007-12-11 15:06:44 EST
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.
Comment 12 Mark J. Cox (Product Security) 2007-12-31 17:57:01 EST
issue is public, opening bug
Comment 13 Tomas Hoger 2008-01-09 06:59:14 EST
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.

Note You need to log in before you can comment on or make changes to this bug.