On Fri, 21 Jul 2000, Andre Hedrick wrote:
> On Fri, 21 Jul 2000, David Ford wrote:
>
> > After watching this thread for a while, I have to stand against adding code.
> > Perhaps I don't understand precisely what Andre is attending to, but I get the
> > gist of it. If it's something that can be patched up...well...do it and we'll
>
> The hardware can not protect itself.
> I used the stand by which it was manufactured by against it with the help
> of the kernel.
>
> I can do the same for SCSI, just harder to break.
>
> 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.
Would you care to actually give *proof* that this can happen under
Linux? Any program that tries to go outside it's memory space should
segfault before overwriting any other memory. If the stack is not protected
by this then why isn't that fixed, and why havn't more exploits for it been
written? I doubt calling a shell as root would be very large, and if what
you say is true then every Linux system out there has a huge security hole
that people are just being kind and not exploiting. Somehow I doubt this is
the case.
> > all go on happily with a new kernel version not even knowing or caring that
> > something changed. If it can't be fixed, why waste time running around in
> > circles?
>
> Bets the heck out of going to the store to buy a new harddrive that can
> have the process repeated upon it for the second new harddrive that can
> have the process repeated upon it for the third new harddrive that can
> have the process repeated upon it for the fourth new harddrive that can
> have the process repeated upon it for the fifth new harddrive that can
> have the process repeated upon it for the sixth new harddrive that can
> have the process repeated upon it for the seventh new harddrive that can
> have the process repeated upon it for the eighth new harddrive that can
> have the process repeated upon it for the ninth new harddrive that can
> have the process repeated upon it for the infinite new harddrive that can
> have the process repeated upon it!
>
> It can destroy hardware faster than you can replace it......
So you fix the hole that is giving the abuser root.
Stephen
-
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 : Sun Jul 23 2000 - 21:00:19 EST