Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: cdrecord local root exploit |
|---|---|
| Date: | Mon, 27 Sep 2004 08:49:18 +0100 (BST) |
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@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: New whitepaper "The Phishing Guide", Daniel Veditz |
|---|---|
| Next by Date: | IPv4 fragmentation --> The Rose Attack, Gandalf The White |
| Previous by Thread: | Re: cdrecord local root exploit, Jason T. Miller |
| Next by Thread: | Re: cdrecord local root exploit, Jason T. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |