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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:27 EST