Messages in this thread | | | Date | Fri, 28 Jul 2000 16:16:56 +0200 (CEST) | From | Marco Colombo <> | Subject | Re: TO HELL WITH IT THEN......(re: disk-destroyer.c) |
| |
On Sat, 22 Jul 2000, Horst von Brand wrote:
> Andre Hedrick <andre@linux-ide.org> said: > [...] > > > When it gets added, I will send you a patch to remove it so your computer > > can be screwed in user land. I think I have a CERT expert showing me that > > the size of disk-destroyer.c in compiled form is smaller than the > > shellcode stack. Therefore you push the stack, and if the PID you push > > into is running a root.root you are TOAST. > > And if they get root and do a "dd if=/dev/zero of=/dev/hda" I'm toast > too. Disable dd(1), cp(1), echo(1), ... for that reason? > > I'm assuming the relevant ioctls are protected by the standard > permissions, so (given sane permissions) only root can blow away the disk. > If a cracker gets root, I'm toast. If the ioctls are "protected" by the > kernel, they'll just do them the hard way. What's new there?
<lurker mode off> It's just a matter of API. When you use socket() and write() to send data over a TCP connection, you expect that only *valid* TCP packets are generated. And i hope that write() checks for a valid pointer. So, if there's a function/syscall to send ATA commands, you expect that it sends only *valid* commands. It doesn't really matters if you can bypass its sanity checks using another (low-level) interface. If there's the need to send *invalid* commands, applications should use the low-level interface. There's nothing strange in that.
> > Sure, if the kernel does wrong stuff it has to be fixed. If the user does > idiotic stuff, it's his/her problem. Unix has always worked that way, and I > like it exactly for that general reason.
Unix always had a FS layer, to allow people (even root) access the disk in certain way. It *does* sanity checks for root, even if it's known that he/she can bypass them opening /dev/hd?.
As root, you have access to many different interfaces to access you IDE disk, and all of the end up in issuing ATA commands:
- open/write/etc. on files - open/write to /dev/hd? - ioctl() (i see this somewhat at lower level than the above); - direct access to controller i/o ports
The existance of the latter doesn't mean all sanity checks in the higher level ones are useless, even if it means that they can bypassed.
Just as when you talk to the network layer "at TCP level" it enforces TCP correctness, but when you talk "at IP level" it lets you generate malformed TCP packets (but not malformed IP packets), i think that when you talk to the disk layer "at ATA level" it should enforce ATA correctness, and of course it won't if you write directly to i/o ports. <lurker mode on>
> -- > Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl > Departamento de Informatica Fono: +56 32 654431 > Universidad Tecnica Federico Santa Maria +56 32 654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ >
.TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |