Message-ID: <Pine.LNX.4.58.0409161222050.26407@guildenstern.oneview.local>
Date: Thu, 16 Sep 2004 12:57:10 -0500 (EST)
From: "Jason T. Miller" <jasomill@...ffstall.com>
To: bugtraq@...urityfocus.com
Subject: Re: cdrecord local root exploit


> I think that the reason the author states that it must be installed
> setuid root is so that it can be run by a normal user to burn cd images
> (versus having to su to root). Try using sudo, or set up something to
> modify the permissions on your cd device to allow it to access them.

This is a much better idea, and what I do in fact. You still have to trust
cdrecord users, though, and aside from sudo's audit logging, it's not
really any safer than the author's suggestion to set cdrecord permissions
to 4710 with group ownership of cdburners, and assigning users trusted to
run cdrecord to the cdburners group.

But that's not the issue. The manpage for cdrecord states that

  If you don't want to allow users to become root on your system, cdrecord
  may safely be installed suid root. This allows all users or a group of
  users with no root privileges to use cdrecord.  Cdrecord in this case
  checks, if the real user would have been able to read the specified
  files.

By design, it's supposed to be "safe", therefore, the problem at issue, if
it exists, is a vulnerability.

I'd suggest to the cdrecord author that he might enable cdrecord to
function without root privileges, even if it can't be "fully functional".
The same manpage states that

  In order to be able to use the SCSI transport subsystem of the OS, run
  at highest priority and lock itself into core cdrecord either needs to
  be run as root, needs to be installed suid root or must be called via
  RBACs pfexec mechanism.

I presume at least some supported OSes provide the ability to assign
permissions to SCSI passthrough on a per-SCSI device basis, so his
statement to

  Never  give  write  permissions  for  non  root  users to the
  /dev/scg? devices unless you would allow anybody to  read/write/format
  all your disks.

is a bit misleading. It's certainly true if you interpret /dev/scg? as a
shell wildcard, but why can't I give permissions for non-root users to the
writable optical devices only, instead of "all [my] disks"? It _seems_
like it would work on FreeBSD and Linux, at least, though I confess to not
having tried it (I only run cdrecord on my desktop machines [using sudo],
where this isn't an issue).

The real-time and lock-in-core stuff certainly improves the reliability of
cdrecord, but is not necessary for its function, so it should be optional
(if it is not already, as I suspect at least some of the supported OSes do
not support such functionality), so the administrator can decide whether
he most values security or reliable cdrecord operation. On modern systems,
and using modern CD-R and DVD[+-]R drives (with large buffers and buffer
underrun protection), it would probably run quite well without such
features, as long as the system is not to heavily loaded. And if it _is_
heavily loaded, the other load may well be more important than a good CD
burn. In any case, the system's administrator, not the author of cdrecord,
should be the one making the call.

  -jtm

On Wed, 15 Sep 2004, Coleman wrote:

> I think that the reason the author states that it must be installed
> setuid root is so that it can be run by a normal user to burn cd images
> (versus having to su to root). Try using sudo, or set up something to
> modify the permissions on your cd device to allow it to access them.
>
> On Mon, 2004-09-13 at 21:51, Volker Kuhlmann wrote:
> > > > echo "cdr-exp.sh -- CDRecord local exploit ( Tested on cdrecord-2.01-0.a27.2mdk + Mandrake10)"
> >
> > > I don't see how this is a bug in cdrecord. It's a bug in Mandrake, caused by
> > > shipping cdrecord setuid root. You could do the same thing with CVS (set
> > > CVS_RSH to /tmp/s) if your distribution was dumb enough to ship cvs setuid
> > > root, I would think, yet that wouldn't be a bug in CVS.
> >
> > The author of cdrecord obstinately argues that cdrecord must be
> > installed suid root, and is explicitly recommended. Especially SuSE,
> > who does not install cdrecord suid root, has taken a lot of flak over
> > this lately (investigate special SuSE copyright in versions 2.01a36 to
> > 40 or so). It also seems that kernel 2.6.8 has changes included which
> > make it impossible(?) not to run cdrecord suid root. Seems like a
> > downhill to me but I'm not really qualified to comment.
> >
> > In any case it would be inappropriate to call it a bug "in cdrecord"
> > when only testing the Mdk version, esp given the amount of patching
> > applied by Mdk. First test a vanilla cdrecord, then other distros.
> >
> > Volker
>

Powered by blists - more mailing lists