Messages in this thread | | | From | "Khimenko Victor" <> | Date | Fri, 21 Jul 2000 23:02:58 +0400 (MSD) | Subject | Re: 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/
| |