Messages in this thread | | | Date | Fri, 21 Jul 2000 22:02:27 +0200 (CEST) | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: TO HELL WITH IT THEN......(re: disk-destroyer.c) |
| |
On Fri, 21 Jul 2000, Khimenko Victor wrote:
> 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.
yes
> > > 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 ?
It will stop this thread and make Andre happy and relaxed :-) seriously speaking as Andre said this patch prevents accidental hdd frying by clumsy root...
> > > 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 ? >
I'm sure there are some...
-- 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/
| |