Bug 130951 - CAN-2004-0801 cupsomatic arbitrary command execution issue
Summary: CAN-2004-0801 cupsomatic arbitrary command execution issue
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: foomatic
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-25 23:13 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2004-11-09 10:11:18 UTC


Attachments (Terms of Use)
foomatic-cmdexec.patch (711 bytes, patch)
2004-08-26 11:46 UTC, 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 21:48 UTC, Josh Bressers
no flags Details | Diff

Description Josh Bressers 2004-08-25 23:13:08 UTC
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 11:46:38 UTC
Created attachment 103115 [details]
foomatic-cmdexec.patch

This is based on the patch that Klaus Singvogel sent.

Comment 2 Josh Bressers 2004-08-26 21:48:52 UTC
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 09:52:29 UTC
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 2004-09-13 12:10:02 UTC
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 2004-09-13 12:12:46 UTC
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 14:03:50 UTC
Removing embargo


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