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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:17 EST