cdrecord trouble

September 15, 2004

This article was contributed by Jake Edge.

Making sweeping statements about the security of a particular program can come back to haunt you rather quickly as the recent case of a local root exploit in cdrecord demonstrates. During a discussion of recent changes in the 2.6 Linux kernel (as covered by LWN), Jörg Schilling, the author of cdrecord, made a comment about the security of that program:

Judging from the number of reports, I would guess that the Linux kernel is much more insecure than cdrecord.

That statement could well be true, but in making it, Jörg may have inspired someone to take a closer look at cdrecord. Max Vozeler recently found that cdrecord fails to drop privileges when it executes an external program, and that users can specify which external program is run via the RSH environment variable. If cdrecord is installed setuid root, any local user can exploit this vulnerability to gain root access; multiple exploits have already been posted on bugtraq.

Jörg recommends installing cdrecord as a setuid root. cdrecord uses the elevated privileges to lock its buffers into physical memory and to request real-time scheduling, both of which reduce the chances of a buffer underrun. In addition, cdrecord opens the SCSI device before dropping privileges back to that of the user who executed it. In the case of a remote device, it executes the command to access that device, but prior to this bug being fixed, it did that with elevated privileges.

Other means for allowing non-root users to burn CDs do exist, but they are less secure, according to Jörg:

What some people did (chmod on /dev/ entries) was definitely always a bigger security risk than running cdrecord suid root.

Another alternative, which is used by some distribution vendors (notably Red Hat and SuSE), is to disallow non-root users from burning CDs; clearly this is the most secure choice, but can be inconvenient for users and system administrators. Many administrators and some CD burning front end programs override this choice and, in this case, that could lead to a large security hole that may not be patched by the distribution. To avoid this possibility, some distributions have issued cdrecord updates even though they do not install the program in a setuid mode; see the LWN vulnerability entry for the current list.

Jörg has fixed this bug in the most recent version of his cdrtools package (2.01a38, available from his cdrecord page).

Index entries for this article
GuestArticles	Edge, Jake

to post comments

cdrecord trouble

Posted Sep 17, 2004 9:10 UTC (Fri) by garloff (subscriber, #319) [Link]

It is not true that SUSE does disallow non-root users to burn CDs/DVDs.

It is true, however, that SUSE does not install cdrecord setuid root.
For this to work, the user needs write permission to the CD recorder
device obviously.

(This will not allow cdrecord to pin memory or use realtime scheduling,
but most recorders have buffer-underrun protection mechanisms (burnfree
and friends) these days, so this is a minor issue.
And SUSE enabled burnfree by default.)

There's two ways to make this work:
* The classical Un*x approach: Add users that should be allowed to burn
CDs to a group and change the device permissions accordingly.
* The modern way: Upon (graphical) login, provide the local user with
a set of permissions defined by the sysadmin. resmgr does handle this
on SUSE Linux systems.

cdrecord as root

Posted Sep 18, 2004 16:24 UTC (Sat) by rfunk (subscriber, #4054) [Link]

Another option for giving cdrecord the root privileges it wants is to
trust only certain users with the ability to run it as root.

I use sudo to run cdrecord, with myself in the cdrom group and the
following line in /etc/sudoers:

%cdrom ALL=NOPASSWD: /usr/bin/cdrecord, /usr/bin/cdrdao

(OK, so the "cdrom" group is misnamed here....)

cdrecord trouble

Posted Sep 20, 2004 10:48 UTC (Mon) by arafel (subscriber, #18557) [Link]

Has he removed the text which claims you're not allowed to modify parts of the program yet? If not, I suspect most distributions won't pick up the latest version, but will just backport the changes.