lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TO HELL WITH IT THEN......(re: disk-destroyer.c)
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 understand the hardware can be destroyed. I also understand that there are a
good number of pieces of PC hardware that have flash on them or like video cards,
are programmable.


> 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.
>
> > 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

Andre, I quite grasp this. I stand by my earlier statement. If it can be fixed,
write the patch and put it in and go on with life. With all this carrying on, it's
just advertising for the malicious kiddie. Patches like this should be written and
quietly introduced into the kernel and a tiny blurb made in the ChangeLog saying
"ATA protocol violations prohibited". If it can't be fixed, the advertising of a
bad design flaw is certainly not a good thing.

Everybody would be inherently safer from the malicious kiddie who doesn't [yet]
know how to break things and may never know.

By carrying on about it for a week, it's a nice honeypot for that malicious kiddie
to search the archives and build a workable exploit to destroy hardware.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."


begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard
\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.667 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site