Re: cdrecord local root exploit

From: Jason T. Miller (jasomill_at_shaffstall.com)
Date: 09/16/04

  • Next message: Mandrake Linux Security Team: "MDKSA-2004:098 - Updated libxpm4 packages fix libXpm overflow vulnerabilities"
    Date: Thu, 16 Sep 2004 12:57:10 -0500 (EST)
    To: bugtraq@securityfocus.com
    
    

    > 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
    >


  • Next message: Mandrake Linux Security Team: "MDKSA-2004:098 - Updated libxpm4 packages fix libXpm overflow vulnerabilities"