Bug 133098 - CVE-2004-0813 SG_IO unsafe user command execution
Summary: CVE-2004-0813 SG_IO unsafe user command execution
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
Whiteboard: NdRvw,public=20040730,impact=moderate...
Keywords: Reopened, Security
Depends On:
Blocks: 186960 232096
TreeView+ depends on / blocked
Reported: 2004-09-21 18:08 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
15 users (show)

Fixed In Version: RHSA-2007-0465
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-11 17:51:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Possible fix (8.85 KB, patch)
2006-08-31 16:01 UTC, Doug Ledford
no flags Details | Diff
Slightly cleaned up and more readable version of same patch (9.01 KB, patch)
2006-09-01 17:39 UTC, Doug Ledford
no flags Details | Diff
Simple PAM support for cdrecord (1.84 KB, patch)
2007-03-26 19:21 UTC, Tomas Mraz
no flags Details | Diff
PAM configuration for cdrecord (/etc/pam.d/cdrecord) (115 bytes, text/plain)
2007-03-26 19:28 UTC, Tomas Mraz
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0465 normal SHIPPED_LIVE Moderate: pam security and bug fix update 2007-06-07 23:32:45 UTC

Description Josh Bressers 2004-09-21 18:08:10 UTC
It is possible that a user with read only access to a device to issue
arbitrary commands (ie 'write' or 'erase firmware').

There is a discussion on the lkml

Comment 1 Alan Cox 2004-09-21 18:35:50 UTC
Should be for RHEL4 surely not RHEL3

Comment 2 Ernie Petrides 2004-09-22 02:00:36 UTC
Alan, wouldn't any RHEL4 exposure to this also occur on RHEL3?

I briefly examined sg_new_write() and sg_ioctl() for the SG_IO
case (in drivers/scsi/sg.c), and both 2.6 and RHEL3 seem to use
"read_only" similarly (but I'm not sure where the alleged bug is).

Comment 3 Mark J. Cox 2004-09-22 08:54:14 UTC

Comment 5 Doug Ledford 2004-10-08 17:48:04 UTC
Well, I agree with Alan.  This is for RHEL4 not RHEL3.  Not only that,
but it appears to be fixed in upstream 2.6 kernels at this point.

So, to answer Ernie's question about where the bug is.  In RHEL3, you
grant access to a block device by giving permissions to the
/dev/{hd,sd,sr,etc.} files.  You grant access to SG_IO ioctls by
setting permissions on /dev/sg files.  So, even if the SG_IO routines
didn't check anything before allowing a user to blank the device or
overwrite a firmware, the user still had to be able to open the
/dev/sg* file associated with the device, not just the normal device file.

When Jens moved the SG_IO functionality out of the scsi layer and into
the block layer, the SG_IO ioctls now became valid ioctls on all block
devices.  So permissions that used to apply only to regular block
device access (/dev/{hd,sd,sr,etc}) now applied to the SG_IO ioctls as
well and this had unintended side effects.   <--- The Bug

To resolve the issue, the 2.6 kernel now implements a read-only vs.
write-required filter on SG_IO packets that compares the requested
operation against a table and determines if the command is allowed
(see verify_command in drivers/block/scsi_ioctl.c in current 2.6 kernels).

So, looks like this was a short lived security issue that only existed
in the 2.6 kernel series for a short while, and doesn't effect RHEL3
at all.

Alan, Ernie, any disagreement on that conclusion?

Comment 6 Ernie Petrides 2004-10-08 18:06:09 UTC
Doug, I concur, and have just verified that /dev/sg* files on
a RHEL3 U3 installation all have 660 (uid "root", gid "disk"),
and thus unprivileged users would not be able to open any of
these character special files in order to perform any ioctls.

Doug/Alan, should this bug be closed now?

Comment 7 Doug Ledford 2004-10-08 18:11:53 UTC
I believe so.  Alan?

Comment 8 Arjan van de Ven 2004-10-08 19:09:08 UTC
Actually our pam setup will give console users write access to
/dev/sg* afaics ....

Comment 9 Alan Cox 2004-10-08 19:49:21 UTC
It isnt supposed to. If our pam_console rules are wrong please open a
pam bug about that. I agree this can closed.

Comment 10 Mark J. Cox 2004-10-11 09:34:35 UTC
To summarize my understanding:

In RHEL /dev/sg* are 660 root.disk and altered to be owned by the
console user at login.  So there is no case where we only issue read
access and don't want write access.  Therefore this particular kernel
issue isn't going to affect RHEL users, closing.

(The bigger issue outside the scope of this bug is that we want to be
able to give the console user write access to a cdrom without them
being able to flash firmware etc).

Comment 11 Alan Cox 2004-10-11 11:34:25 UTC
Disagree entirely. The bug allows every user to bypass file
permissions, it also allows them to load modified firmware that
bypasses system security and it allows any local user exploit to
trivially get CAP_SYS_RAWIO and/or destroy hardware.

One trivial end user mistake, one app run by that user that should not
have been and game over send computer back to Dell.

cdrecord supports setuid operation and has been audited for it, its
also got a fairly good record and having reviewed the code seems far
more secure than allowing all users to own the computer.


Comment 12 Doug Ledford 2004-11-26 14:10:55 UTC
Alan: Are you wanting the /dev/sg* permissions modified or are you
wanting a kernel change?  If it's the /dev/sg* permissions, then this
bug needs reassigned to whomever owns the pam stuff and another bug
should be opened on cdrecord et al to get them whipped into shape for
suid operation so that user's don't suddenly stop being able to burn
CDs when they get the relevant security update.

Comment 14 Mark J. Cox 2005-05-26 12:02:57 UTC
Note that there has been considerable patches added after the 2.6.8 upstream
patch to correct this, and SUSE had CAN-2004-1190 also issues for "firmware
overwrites /dev/cdrom".  For many details see 

Comment 19 Tomas Mraz 2005-09-12 14:59:38 UTC
The /dev/sg* permissions would be modified by pam_console only if they are
linked by udev (or kudzu) as /dev/cdrom* or /dev/cdwriter*

The same applies to /dev/sd* and /dev/hd*

Comment 32 Chip Coldwell 2006-08-10 15:47:30 UTC
Doug, if I follow your remarks in comment #5 correctly, this bug should be
against either pam_console or RHEL-4 kernel, but not RHEL-3 kernel.  Is that
still your opinion?

I followed the recent thread (flamewar?) on the linux-scsi mailing list. 
Upstream seems to be working toward a per-device /sysfs-based solution to move
the policy decision about which SCSI commands are allowed by SG_IO ioctls out of
the kernel.  This is not anywhere near finished yet, though.  In the meantime,
the verify_command function in drivers/block/scsi_ioctl.c is already in the
RHEL-4 kernel.

So what exactly is the bug?


Comment 36 Doug Ledford 2006-08-10 18:18:16 UTC
You could probably update pam to make cdwrite devices owned by root.cdburner,
create the new cdburner group, and make cdrecord sgid cdburner.

Comment 39 Doug Ledford 2006-08-31 16:01:26 UTC
Created attachment 135302 [details]
Possible fix

OK, this might do the trick.  It's similar to my original patch, the main
difference being that it adds a switch (dev_type) statement and for the common
bootable device, TYPE_DISK, TYPE_WORM, TYPE_ROM, TYPE_MOD, it activates the
command filtering and in the event of a blocked opcode it warns exactly once
for each opcode (and if you are root it warns but then allows the opcode
anyway).  This way, non-bootable devices are not broken nor affected, bootable
device are protected plus we will have the ability to have people run things as
root to get past the limitations and should we need to train this, we will know
the opcode we need to train from the block messages.

I only worked on the sg file access because A) the block layer doesn't have
SG_IO ioctl capability and B) the scsi layers SCSI_IOCTL_SEND_CMD is root only,
so that only leaves the sg.c file as a possible point of weakness.

I still contend this has the possibility of breaking a *lot* of customer
setups.  Things like assigning raid device files to group wheel and making them
rw for wheel, then having admins run hardware raid management utilities without
being root, stuff like that.  But, at least by limiting the restrictions to
bootable devices we are limiting the overall amount of breakage.

Comment 41 Doug Ledford 2006-09-01 17:39:38 UTC
Created attachment 135398 [details]
Slightly cleaned up and more readable version of same patch

This makes the previous patch slightly more readable and the logic in the
actual command tests a little easier to follow.  This is the patch I actually
submitted internally for review/possible inclusion in the kernel.  As noted in
my internal email, I expect this patch to break some setups.  For example, late
model Plextor CD burners will require the user to su to root before running
cdrecord or else they won't work.  Additionally, it's possible some raid device
management software will now need to be run as root where it used to work just
by giving administrators read/write permissions to the raid management device. 
However, there is nothing that should fail to work if the user has run the
command with root privileges.  So, in the event that breakage does occur, the
usage of sudo or something like console-helper to run the command as root will
work around the problem.

Comment 57 RHEL Product and Program Management 2007-01-23 16:01:21 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

Comment 59 Alan Cox 2007-01-23 16:17:52 UTC
Indeed. I'll reopen this until either its fixed or someone fires me. Its a
disgrace and those involved should be embarrased.

Comment 72 Josh Bressers 2007-03-13 21:11:32 UTC
I've filed bug 232096 against cdrecord and I'm moving this bug to be against
pam.  cdrecord can use consolehelper to let the local user execute the command
as root.  pam_console should not allow local users access to the /dev/sg devices.

I've marked bug 232096 as depending on this bug.

Comment 73 Harald Hoyer 2007-03-15 13:03:24 UTC
Can I do strange things to other SG devices with cdrecord being executed as root?
Can cdrecord be used to gain root access?

Comment 74 Josh Bressers 2007-03-15 13:33:04 UTC
We will probably need to add a few patches to our cdrecord.  We've not fixed
flaws that could gain root in the past since it wasn't suid root.  I'll find the
list and note what we'll need in bug 232096.

AFAIK a user can't do anything out of the ordinary to non cd writers with cdrecord.

Comment 75 Doug Ledford 2007-03-15 14:25:50 UTC
Can you make consolehelper start the program as sgid <something> instead of suid
root?  If so, you could still do the "make cdburner sg devices owned by group
cdburner and group writable" and use consolehelper to set the program to sgid
cdburner, which avoids any possible root compromise holes in cdrecord.

And no, cdrecord won't futz with other devices willingly (although I don't know
if it can be tricked).

Comment 76 Josh Bressers 2007-03-15 14:30:21 UTC
Yes, this makes more sense.  Thanks Doug.

Comment 77 Bill Nottingham 2007-03-15 14:32:25 UTC
That's somewhat significantly more work, as you need something that tracks CD
burners and hotplug and knows to change the ownership to the CD groups - we
don't have any of that code (that code only exists for pam_console, and only
changes to the user). Unless I'm forgetting what pam_console can do.

Comment 78 Alan Cox 2007-03-15 14:51:42 UTC
cdrecord is designed to run setuid. not setgid. Its internal code is tested for
setuid not setgid cases and it handles setuidness internally and explicitly already.

Yeah root is the *wrong* user but group might need a tweak to cdrecord if unlucky. 

Doug is right that cdrecord won't futz with other devices, if it is in say
"setgid disk" category then it'll still only talk to CD devices. It's actually
very careful because on many OS's it has to run setuid root to do anything at all.

Comment 79 Tomas Mraz 2007-03-19 13:46:13 UTC
Note that when a command is run through consolehelper it is not 'setuid root' it
is run with both real and effective uids as root and this is certainly not what
we want. We would need to patch userhelper to add support for running program
with only effective id set to root.

Comment 80 Josh Bressers 2007-03-20 17:20:47 UTC
Hmm, that won't work.  How hard is it going to be to set cdrecord to be setuid
root then, and restrict execution to only the local users?

Comment 82 Tomas Mraz 2007-03-26 18:06:42 UTC
Unfortunately consolehelper doesn't have this option. But there is another
option - add a PAM authentication patch to the (setuid root) cdrecord.

Comment 83 Josh Bressers 2007-03-26 18:20:34 UTC
How much work would that be?  I've not done a lot of pam development.

Comment 84 Tomas Mraz 2007-03-26 19:21:44 UTC
Created attachment 150938 [details]
Simple PAM support for cdrecord

Actually it is pretty simple. The patch (untested) should provide that - it
will call PAM if the cdrecord is called with euid != uid && euid == 0.

Comment 85 Tomas Mraz 2007-03-26 19:28:51 UTC
Created attachment 150940 [details]
PAM configuration for cdrecord (/etc/pam.d/cdrecord)

Comment 86 Pete Graner 2007-03-27 13:05:43 UTC
DEV ACK. Pls lets make this one go away... correctly! Tomas Thanks!

Comment 88 Tomas Mraz 2007-03-27 14:15:51 UTC
One question - what about users who modified their console.perms - should there
be a %post script in the PAM package which would remove the /dev/cdwriter* from
the file using sed?

It can be potentially dangerous to mess with user modified files, also .rpmnew
file will be created so it is questionable whether it is necessary. On the other
hand the security problem will be unresolved if the /dev/cdwriter* is not
removed from console.perms.

Comment 89 Josh Bressers 2007-03-27 14:28:47 UTC
As long as we note the change in the errata text, this won't be an issue.  We
should let users with modified console.perms files fix them if they're
interested in this flaw.

Comment 91 Harald Hoyer 2007-04-03 12:13:52 UTC
what about:

Patch with pam and make them suid also?

Comment 92 Doug Ledford 2007-04-03 12:30:18 UTC
cdrecord and cdrdao need cd writer write access.  all the others in your list
should be  fine with just read access (last I knew, they don't use raw scsi
commands to talk to the device, just block access).  So, being that they only
need read access, I don't know if you'll have to go all the way to suid root or
some such, or whether permissions could be set to simply allow read access for them.

Comment 93 Alan Cox 2007-04-03 12:40:06 UTC
readcd also can use /dev/sg stuff I believe.

The others just need read access via the normal device file

Comment 94 Tomas Mraz 2007-04-03 13:02:55 UTC
Yes but even for the read access to /dev/sg you have to make the readcd suid
because /dev/sg nodes cannot be readable for all.

Are cdrdao and readcd actually written so they drop priviledges if they are made

Comment 97 Red Hat Bugzilla 2007-06-11 17:51:15 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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