Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 130951

Summary: CAN-2004-0801 cupsomatic arbitrary command execution issue
Product: Red Hat Enterprise Linux 3 Reporter: Josh Bressers <bressers>
Component: foomaticAssignee: Tim Waugh <twaugh>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-09 10:11:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
foomatic-cmdexec.patch
none
Here's a more detailed patch from Till, it's expected to go into upstream. none

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