lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: TO HELL WITH IT THEN......(re: disk-destroyer.c)
In <Pine.LNX.4.21.0007212009040.5384-100000@tricky> Bartlomiej Zolnierkiewicz (dake@staszic.waw.pl) wrote:

> On Fri, 21 Jul 2000, Andre Hedrick wrote:
>> On Fri, 21 Jul 2000, Ove Ewerlid wrote:
>>
>> > I like Andre's perfectionist approach at the protocol level.
>>
>> Thanks,
>>
>> Now to restate that it is possible to push the shellstack with the
>> mini-code that is called disk-destroyer.c with out being root and wax your
>> system. I hate having to expose everything, but now the hackers of the
>> world know now to take down Linux Boxes one by one.
>>
>> You now have no choice, the security issue is exposed.
>>
>> Andre Hedrick
>> The Linux ATA/IDE guy

> ...damn... I'm a bit tired of this discussion...

> Andre, are you trying to say that you don't need to have r00t to make
> some hdd-barbecue? If so wouldn't Linus have applied the patch? It's
> obvious that you can make silly things mixing some holes and d-destroyer.c
> Your patch is helpful, but it's "security through obscurity", you can
> still fry hdd after getting r00t, only diffirence will be a bigger exploit
> and more time wasted on writing it...

Not much more. Really. Some pattern-serach over /dev/kmem will help for sure :-)
It's stupid thing to try "security through obscurity" when the whole source
code is exposed to world.

> you are exaggerating or you can't clearly explain what do you mean...
> but patch should go in anyway...

I don't think so. This patch is small and non-intrusive, so perhaps it's Ok
to add it to kernel but still it buys you effectively nothing so waht's the
point ?

> BTW: software may (but don't have to) damage BIOSes, firmwares, CPUs
> (programming PLL on mobo), older monitors, ISA/PCI cards (programming
> southbridge to get ISA/11Mhz and PCI/41.5Mhz)... etc...
> just imagine advanced worm (similar to the one discribed in some
> lcamtuf's project) making use of all hardware "features"... ugh...

> The ONE and ONLY solution is r00t without direct access to hardware...

Yeah. Hmm. Looks like I can userstood now: if direct access to hardware
(and to /dev/kmem, of course) is disabled (some router or firewall so
capabilities are removed from system) but you STILL need HDIO_DRIVE_CMD
then yes, in this RARE scenario this patch is usefull. Huh. Someone knows
at least ONE system in such configuration and with such need ?




-
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    [W:0.305 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site