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]

Date: Mon, 27 Sep 2004 08:49:18 +0100 (BST)
From: Dr Andrew C Aitchison <A.C.Aitchison@...ms.cam.ac.uk>
To: "Jason T. Miller" <jasomill@...ffstall.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: cdrecord local root exploit

On Thu, 16 Sep 2004, Jason T. Miller wrote:

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

At this point trusting the kernel to enforce different permissions
on different scsi devices is probably better than trusting cdrecord,
but your suggestion is (only) as good as the kernel's ability to
sanitize scsi requests. If I can send a SCSI request down the SCSI
bus I have the opportunity to exploit any hole in that subsystem.
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.
Since most CD writers are ide-scsi, the scsi permissions enforcer
needs to sanitize requests as they will appear once translated into IDE 
requests, making the problem harder still.

As I say this may well be less of a problem than trusting cdrecord,
but if I were the author of cdrecord but not the kernel I wouldn't
guarantee the safety of the kernel on this (although I might not
declare it unsafe).

-- 
Dr. Andrew C. Aitchison		Computer Officer, DPMMS, Cambridge
A.C.Aitchison@...ms.cam.ac.uk	http://www.dpmms.cam.ac.uk/~werdna