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)

On Fri, 21 Jul 2000, David Ford wrote:
> 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.
>

Yes, do it micro$oft's way... Do you think that this is really hard to
discover? I have been recently reading T13 docs and I thought that it
would be nice to try some things (similar to destroy-disk.c) when I
have some time... now I'm really happy that I didn't have time to try
them... :-)

Sendmail people once fixed something without documenting it in
changelog... and most of admins were too lazy to upgrade to new sendmail
because there weren'nt important changes... later there was exploit
using this fixed thing... get it?
By doing silent fixes you make people thing that they don't need to
upgrade... IMHO proper way of fixing security issues is the way of
how capabilities "bug" have been fixed...
Fast spreading of information have pros and cons, and you have to deal
with them... You know about some security hole... but malicious bastards
also...

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

IMHO good sysadmin shouldn't be afraid of script-kiddies...

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

Andre revealed "exploit" beacause most (all?) of his opponents were too
lazy to look at patch and kernel's code and see what it is all about!

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

--
Bartlomiej Zolnierkiewicz
<bkz@linux-ide.org>


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

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans