Bug 130951 - CAN-2004-0801 cupsomatic arbitrary command execution issue
CAN-2004-0801 cupsomatic arbitrary command execution issue
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: foomatic (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-08-25 19:13 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-09 05:11:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
foomatic-cmdexec.patch (711 bytes, patch)
2004-08-26 07:46 EDT, Tim Waugh
no flags Details | Diff
Here's a more detailed patch from Till, it's expected to go into upstream. (8.65 KB, patch)
2004-08-26 17:48 EDT, Josh Bressers
no flags Details | Diff

  None (edit)
Description Josh Bressers 2004-08-25 19:13:08 EDT
The cupsomatic driver in foomatic has an issue where if a properly
named file is handed to lpr for printing, it can cause arbitrary
command execution.

I'll attach the patch when it becomes available.

Fedora core is handled by bug 130949

This issue should also affect RHEL2.1
Comment 1 Tim Waugh 2004-08-26 07:46:38 EDT
Created attachment 103115 [details]

This is based on the patch that Klaus Singvogel sent.
Comment 2 Josh Bressers 2004-08-26 17:48:52 EDT
Created attachment 103143 [details]
Here's a more detailed patch from Till, it's expected to go into upstream.
Comment 3 Tim Waugh 2004-08-27 05:52:29 EDT
Although RHEL2.1 includes the affected code, it does not include CUPS
-- lpdomatic is used instead of cupsomatic.

I think there are some dangerous bits of code in there too.
Comment 4 Mark J. Cox (Product Security) 2004-09-13 08:10:02 EDT
From Tim Waugh:

The exploit certainly works (with foomatic 3.x) but on closer
inspection it looks like this *particular* exploit only affects the
foomatic-rip script, and that first appeared in foomatic-3.0.  We ship
foomatic-2.0.2 in RHEL3.

There were other problems that I fixed however, including an exploit
via the job's title.  I can't see any way of exploiting any of these
from the default installation though, and even when customized it has
to be a very unusual type of customization.

To get an exploit to work on RHEL3 I think the administrator would
have to configure CUPS to get foomatic to convert text jobs to
PostScript, rather than performing the task with its own pstops program.

For RHEL-2.1, the only dangerous "open" in lpdomatic was for the data
blob file, which is not user-configurable but may only be changed by
the administrator.

So it actually looks to me like we might not need an advisory here.
Comment 5 Mark J. Cox (Product Security) 2004-09-13 08:12:46 EDT
I'm in agreement, this does not require a security advisory and can
simply be fixed with the next update that happens to require updated
foomatic packages.

(Leaving bug open until it becomes unembargoed)
Comment 6 Josh Bressers 2004-09-15 10:03:50 EDT
Removing embargo

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