Red Hat 9 and Fedora Core 1 shipped with console.perms granting r/w to /dev/sg devices for the console user. This allows any console user to physically destroy hardware as well as to flash compromised firmware and obtain unlimited access to the system. In certain situations file systems can be accessed bypassing security permissions as any user. Fix: The /dev/sg devices should never be assigned to the user, only to a safe group. Cdrecord is designed to run setuid or setgid and has been audited for this kind of use. The fixed security module should remember to depend on the updated and fixed for setuid cdrecord (see FC2 updates) Fedora Core 2 and later do not contain this mistake. ------- Additional Comments From alan.org.uk 2004-10-10 04:34:10 ---- As a PS: the firmware update is not a hypothetical issue - DVD firmware is disassembled regularly and hacked for region code removal already. ------- Additional Comments From marcdeslauriers 2004-10-10 17:55:22 ---- Could you be a bit more specific in what changes exactly you are referring to. AFAICT console.perms is relatively identical between rh9 and fc2 and cdrecord in FC2 updates is not setuid... ------- Additional Comments From tometzky.pl 2004-10-10 20:38:38 ---- IFAIK FC2 has a kernel 2.6.8 which does not allow sending SCSI commands to devices by non-root users if they they have write permissions to /dev/sg and, I think, even when cdrecord is setuid root. http://fedoranews.org/colin/fnu/issue16.shtml Fedora Core 2 kernel upgrade breaking CD recording http://lwn.net/Articles/98379/ That's why they can have console.perms the same and they're safe. ------- Additional Comments From alan.org.uk 2004-10-11 03:49:31 ---- Fedora Core 2 and later don't use /dev/sg for CD burning, but the SG_IO interface. SG_IO was itself insecure but this was fixed in 2.6.8 and a nice solution added during 2.6.9 development. Thus FC2 does not hand over access to /dev/sg*. The 2.4 kernels have no filtering access functionality, instead they expect CD burners to be root or setuid root. cdrecord supports this mode of operation. ------- Additional Comments From rob.myers.edu 2004-10-11 05:26:30 ---- is there anything other than cdwriter and scanner that can be linked to /dev/sg? if not, does the following patch look sufficient? diff -uNr ./modules/pam_console/console.perms.orig ./modules/pam_console/console.perms --- ./modules/pam_console/console.perms.orig 2004-10-11 11:11:26.000000000 -0400 +++ ./modules/pam_console/console.perms 2004-10-11 11:23:03.000000000 -0400 @@ -24,12 +24,12 @@ <sound>=/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer \ /dev/sound/* /dev/beep -<cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom* +<cdrom>=/dev/cdrom* /dev/cdroms/* /mnt/cdrom* <pilot>=/dev/pilot <jaz>=/mnt/jaz* <zip>=/mnt/pocketzip* /mnt/zip* <ls120>=/dev/ls120 /mnt/ls120* -<scanner>=/dev/scanner /dev/usb/scanner* +<scanner>=/dev/usb/scanner* <rio500>=/dev/usb/rio500 <camera>=/mnt/camera* /dev/usb/dc2xx* /dev/usb/mdc800* <memstick>=/mnt/memstick* ------- Additional Comments From alan.org.uk 2004-10-11 10:44:06 ---- Those are the only ones I can think of. There are weird sg users outside of disks, scanners, cd etc but we don't do permission magic for them. ------- Additional Comments From rob.myers.edu 2004-10-11 11:59:33 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Packages to QA for FC1: applied above patch changelog: * Mon Oct 11 2004 Rob Myers <rob.myers.edu> 0.77-16.legacy - - fix #2146 Incorrect /etc/security/console.perms 9bd7120a3b9f8d2fc21e22f6e70a2b92a35e51ac http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/pam-0.77-16.legacy.src.rpm c6f90fd9e96d6a1f764954686110f191773824b5 http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/pam-0.77-16.legacy.i386.rpm 968113b6bf5a79f4b03753113738f189f3023caa http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/pam-debuginfo-0.77-16.legacy.i386.rpm f5d4e6c6e43e744ccc59ba7f68f9001e7c4a41fb http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/pam-devel-0.77-16.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBawHmtU2XAt1OWnsRAkRDAKC9z/+i8TxKIb3VZQu7DU3q0hZ1tQCgutpX u0b7A6GZM2WtUBmhJniYMus= =y+wf -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2004-10-11 12:33:59 ---- In response to comment 7: Won't we need new cdrdao, cdrtools, dvd+rw-tools and dvdrtools packages all with the binaries set setuid to go with your new pam packages, or am I missing something? And won't we break people using scsi scanners? ------- Additional Comments From alan.org.uk 2004-10-11 12:52:27 ---- cdrecord supports being run setuid (you need to pick up the security fixes that went out for FC2/3 but it was always intended to run that way. The others may be trickier. It is the kind of thing that needs notes with the patch (painful learing from 2.6.8 when we fixed SG_IO). ------- Additional Comments From cra 2004-10-12 08:54:49 ---- I agree that we should just remove the console.perms from /dev/sg* and publish security fixed cdrecord etc. so it is safe to run it suid-root. I don't think we should go out of our way to make legacy distros user-friendly if the tradeoff is less security. If people want the "proper" fix for this, they should upgrade to FC2/FC3. Most of these users would be desktop users anyway, which should be less of a problem for upgrading, than e.g. servers. ------- Additional Comments From rob.myers.edu 2004-10-21 06:38:27 ---- here is the redhat bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133098 ------- Additional Comments From rob.myers.edu 2004-10-21 10:54:42 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedora Legacy is committed to patching security vulnerabilities _and_ maintaining compatibility. This is one of those bugs that following one principle violates the other. My view is that patching security vulnerabilities is more important than maintaining compatibility. This is my view, and I realize that others may have different views. While cdrecord and cdrdao have in the past had exploits[1,2] when they were run with the suid bit set, such a configuration may be desirable to maintain compatibility. To that end, I have rebuilt the latest cdrtools from FC2. The admin may enable the suid bit after installation if desired. [1] http://www.forbiddenweb.org/viewtopic.php?p=38774 [2] http://www.securityfocus.com/archive/1/374341/2004-09-03/2004-09-09/0 packages to QA for FC1: changelog: * Thu Oct 21 2004 Rob Myers <rob.myers.edu> - 8:2.01.1-0.FC1.1 - - change version from FC2 to FC1 to test for FL bug #2146 - - rebuild * Wed Sep 29 2004 Harald Hoyer <harald> - 8:2.01.1-0.FC2.1 - - erratum for 2.6.8 kernel files: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/cdrtools-2.01.1-0.FC1.1.src.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/cdda2wav-2.01.1-0.FC1.1.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/cdrecord-2.01.1-0.FC1.1.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/cdrecord-devel-2.01.1-0.FC1.1.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/cdrtools-debuginfo-2.01.1-0.FC1.1.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/mkisofs-2.01.1-0.FC1.1.i386.rpm sha1sums: 2bed792e1c81bc918d1646f830701dccfdb122ea cdda2wav-2.01.1-0.FC1.1.i386.rpm 577d6efaa35382f407fb67f0727722ee02116c14 cdrecord-2.01.1-0.FC1.1.i386.rpm 520044d14e993f9136177d2ce75e3d412bb362ad cdrecord-devel-2.01.1-0.FC1.1.i386.rpm eadfe884996f700199906cb82e5b94e810e4ac36 cdrtools-2.01.1-0.FC1.1.src.rpm b06409aea57ff5235ed92e52b4070f9fc7b31112 cdrtools-debuginfo-2.01.1-0.FC1.1.i386.rpm da45c8ac7b09ae0b4c3f6fca05dbe40ec846dd91 mkisofs-2.01.1-0.FC1.1.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBeCF9tU2XAt1OWnsRAjRnAJ9T7nKDgKppg0p2Kri1JNp5NF8AKQCfffl4 fj6ghRZIGSVJTIro/2nqGq0= =gHP+ -----END PGP SIGNATURE----- ------- Additional Comments From josh.kayse.edu 2004-11-22 09:42:23 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on the FC1 Packages: eadfe884996f700199906cb82e5b94e810e4ac36 cdrtools-2.01.1-0.FC1.1.src.rpm 9bd7120a3b9f8d2fc21e22f6e70a2b92a35e51ac pam-0.77-16.legacy.src.rpm - - cdrtools builds cleanly - - pam needs pam-devel to build - - spec files look good - - patches look good - - cdrtools identical to FC2 package - - pam source files the same - - installs cleanly - - runs cleanly + PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBokEOwnUFCSDmt7ERAkBsAJ9k19vRJQ2whXwtu6FCDBrPUBclwACggGV4 WtcHEVDSQuJ9cN6WMQkYycQ= =eKVJ -----END PGP SIGNATURE----- ------- Additional Comments From pekkas 2005-02-26 01:08:49 ---- This probably applies to RHL73 as well -- at least the patch does? Cdrtools has been updated, obviating the need to rebuild them EXCEPT if we want to ship cdrecord etc. setuid or setgid root by default (i.e., not requiring the user to set them himself). Two questions: - Is it OK to require the users to add setuid root themselves? - If we want to fix this, this should be folded back to the other PAM update, #2010 (I'll add a dependency) ------- Additional Comments From pekkas 2005-02-26 06:57:33 ---- Marc in #2010: "I don't think we should fix 2146. It will break too many things and no other distro seems to have fixed it. I think we should just stick with [#2010]". FWIW, I'm OK with this approach. I can live with it either way. But in any case, we should make a decision ASAP and either agree to fix this one, or just close it and move on. ------- Additional Comments From marcdeslauriers 2005-02-26 08:07:30 ---- We won't be fixing this. If this security issue is important to someone, they can modify the console.perms themselves or upgrade to a more recent distro. ------- Bug moved to this database by dkl 2005-03-30 18:28 ------- This bug previously known as bug 2146 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=2146 Originally filed under the Fedora Legacy product and Package request component. Unknown priority P2. Setting to default priority "normal". Unknown platform PC. Setting to default platform "All". Unknown severity critical. Setting to default severity "normal". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.