bugtraq - Re: cdrecord local root exploit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0409280016150.21359@guildenstern.oneview.local>
Date: Tue, 28 Sep 2004 01:22:17 -0500 (EST)
From: "Jason T. Miller" <jasomill@...ffstall.com>
To: Dr Andrew C Aitchison <A.C.Aitchison@...ms.cam.ac.uk>
Cc: "Jason T. Miller" <jasomill@...ffstall.com>,
	bugtraq@...urityfocus.com
Subject: Re: cdrecord local root exploit

On Mon, 27 Sep 2004, Dr Andrew C Aitchison wrote:

> I belive at one time the kernel wasn't trusted to stop a malicious
> user from generating a SCSI request which was received by a different
> device than the one the kernel was told was the target.

Even if it were, there's a more subtle security hole lurking here -- most
recordable optical drives allow firmware updates via the bus.  Aside from
filtering specific commands to specific devices (error-prone and difficult
to maintain, especially as the commands in question are frequently
undocumented), there's nothing the kernel can do to prevent the uploading
of malicious firmware that, among other things, could proxy SCSI commands
to other devices on the bus. This probably isn't an issue on a
single-initiator bus like IDE, but it's certainly possible in the
multiple-initiator world of SCSI.

In addition, there are many opportunities for denial-of-service,
particularly with older devices that don't do a very good job of sharing
the SCSI bus in the first place (e.g., devices that don't support
disconnect/reconnect), and devices that allow SCSI controller
configuration via mode pages (e.g., disabling D/R). Of course, it's
probably a bad idea to put the first class of devices on the same bus with
critical devices in the first place, but I digress.

With that said, the safest way to run cdrecord seems like the following:

 - create a user (e.g., cdrecord) and a group (e.g., cdrecord-user)
 - give the cdrecord user (_not_ the group) permission to access any
resources necessary to run cdrecord
 - chown cdrecord:cdrecord-user cdrecord
 - chmod 4550 cdrecord

This is simply the principle of least privilege. Cdrecord shouldn't need
to be root -- it only needs certain permissions to get its job done.
Cdrecord users don't need to be able to send arbitrary SCSI commands --
cdrecord itself does.

The notion that a program must be root if an ordinary user doesn't have
the necessary permissions by default is a dangerous one. Sometimes UNIX
makes this unavoidable (root-based security checks, e.g., privileged port
access), but, curiously, I see it more in the Windows world, where lots of
software wants to run as either a local Administrator or LocalSystem
(i.e., as a part of the TCB) instead of as an ordinary user with whatever
additional privileges are required, even though more granular security is
available (e.g., why does the Windows Time service need to run as a part
of the TCB? It needs to be able to set the system's clock, but NT has a
separate privilege [SeSystemTime] for this, presumably for a reason).

If one were to re-implement cdrecord with security in mind, it may make
sense to separate it into two executables:
 - a front-end program, running as the user, which does command-line
processing, file access, and other tasks not directly related to device
control
 - a "device access" program, running as cdrecord, which contains the
minimum amount of code necessary to control the optical drives. The
front-end would send it generic requests (e.g., write, finalize) which
would then be translated into the appropriate SCSI commands.

This way, only the smaller (and, presumably, easier to audit) "device
access" program would have to be trusted with raw SCSI access.

Since the "device access" portion of cdrecord is probably the largest and
most error-prone portion of the code (I assume this from my own experience
writing SCSI software, not from inspecting the cdrecord sources), it is
questionable whether this would be worth the trouble. However, if
implemented as a generic, portable "burner daemon" with a simplified API
that could be useful to multiple front-end programs (e.g., X11 front ends,
music players, backup software), it could be worthwhile.

 -jtm