Bug 807154 - (CVE-2012-4542) VUL-1: CVE-2012-4542: kernel: SCSI filtering bypass
(CVE-2012-4542)
VUL-1: CVE-2012-4542: kernel: SCSI filtering bypass
Status: RESOLVED WONTFIX
: 853890 (view as bug list)
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Normal
: ---
Assigned To: Hannes Reinecke
Security Team bot
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-02 10:29 UTC by Marcus Meissner
Modified: 2014-03-12 09:47 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2013-03-02 10:29:36 UTC
is public, via cvedb

CVE-2012-4542


block/scsi_ioctl.c in the Linux kernel through 3.8 does not properly consider the SCSI device class during authorization of SCSI commands, which allows local users to bypass intended access
 restrictions via an SG_IO ioctl call that leverages overlapping opcodes.
    
    

Reference: CONFIRM: https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=76a274e17114abf1a77de6b651424648ce9e10c8
Reference: CONFIRM: https://bugzilla.redhat.com/show_bug.cgi?id=875360
Reference: MLIST: http://marc.info/?l=linux-kernel&m=135904012416042&w=2
Reference: MLIST: http://marc.info/?l=linux-kernel&m=135903967015813&w=2
Comment 1 Swamp Workflow Management 2013-03-02 23:00:23 UTC
bugbot adjusting priority
Comment 3 Hannes Reinecke 2013-09-04 12:12:56 UTC
What an interesting idea.

So to recap, this is just to prohibit commands from a different commandset being send to a device, right?

In most cases this _should_ be errored out by the device itself, as the command won't be supported. So we would only have a problem if

a) Commands with the same opcode have a different meaning for different commandsets

and

b) these overlapping commands would have different protection rules (read/write)

After a cursory glance only very few commands are affected by this; I'll be checking the spec.
Comment 4 Hannes Reinecke 2013-09-04 13:48:25 UTC
Also, the current filter set is geared for CD/DVD-ROM. As this is the only type currently supported for user access it should be perfectly sufficient to just check for commands which are currently filtered, but might be filtered incorrectly due to a commandset overlap.

Or is it desireable to have a user access for normal block devices, too?
Comment 5 Marcus Meissner 2013-09-05 14:04:03 UTC
The normal user should only be able to access the cdrom style block devices, the others not. (i hope that was the question for me ;)
Comment 6 Marcus Meissner 2013-12-06 09:50:44 UTC
*** Bug 853890 has been marked as a duplicate of this bug. ***
Comment 7 Hannes Reinecke 2014-03-12 09:47:16 UTC
As a 'normal' user should only be able to access cdrom style block devices, _and_ these commands are already filtered out correctly I fail to see the need to modify anything here.

The mentioned CVE only applies for devices which are _not_ cd-roms and where an accidental command set overlap _might_ allow the user to send down commands to that device which _should_ have been filtered out.

But as we're only concerned with cdrom devices, and all other types are not user-accessible we're fine.