Re: disk destroyer, etc

From: Khimenko Victor (khim@sch57.msk.ru)
Date: Mon Jul 24 2000 - 04:31:49 EST


In <Pine.LNX.4.21.0007240239040.12536-100000@tricky> Bartlomiej Zolnierkiewicz (dake@staszic.waw.pl) wrote:
> On Mon, 24 Jul 2000, Taso Hatzi wrote:
>> Is this a problem for all brands of IDE drive?
>> If not, then which brands protect themselves?

> What about doing some tests, any volunteers :-)

> Or let's write some diagnostic tool:
> "
> [root@grill.now]# ./d2b
> brick-test: /dev/hda Model X FwRev Y: is vulnerable... :-)
> brick-test: /dev/hdc Model A FvRev B: is vulnerable... :-)
> ...
> "

> [forgive me my stupidity...]

I forgive you. It DOES NOT work this way. I'll try to explain what happened
and then you'll have more information to judgle. Most currect IDE disks
(as well as SCSI disks) have upgradeable firmware. The question is: how
this firmware is upgraded ? Answer: with commands not included in ATAPI
specification. Thus if we'll forbid usage of such commands then we are
safe, right ? Wrong. Even if Linux IDE driver have filter in place it's
not a big deal for cracker to remove such filter IF he has CAP_SYS_RAW.
So it works as security plate ONLY when cracker can not get CAP_SYS_RAW.
And since interface to send commands straight to hardware is dangerous
and it IS raw i/o interface then best fix look like addition of
capable(CAP_SYS_RAW) in right place (two lines) and not big Adnre's patch
(60K) to filter out vendor-specific commands. As safety tool this thing is
also [mostly] useless: it's VERY hard for misbehaved program to destroy
something with this raw i/o UNLESS it's driven by cracker via buffer
overflow or something and then - see above.

Back to question: what about disk destroyer ?
-- letter1 --
I used a bad word of choice. I can not DISKTOBRICK.
But can genrate code that will attempt and may have success.
Regardless do you want access to such attempts available in the kernel?
Unchecked?

Andre Hedrick
The Linux ATA/IDE guy
-- letter2 --
I am talking about attempting to invoke unknown vender specific commands
They do comply with the SPEC but are not part of the SPEC.
Since I do not have the priviledge of knowing these facts, but know they
exist. You can not allow a rouge driver attempt to invoke these commands.

This is how disks are/can be damaged.

Controllers are limited to what the driver tells it to do.

This is why it is a kernel level issue, I am taking responsiblity for not
fixing this earlier but I just figured it out have being wacked in the
head with it three months ago.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy
-- cut --

As you can see this disktobrick not exist yet at all. It's pretty obvious
that disktobrick CAN be created (for some HDDs at least) but for each and
every HDD flavour you'll need you own version (see above). What's more:
there are exist HDD hurtable with CORRECT ATAPI commands. So it really
DOES NOT look like we can get significant gains with Andre's plates in place.

P.S. I hope it's correct summary but of course I can be wrong.

-
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 : Mon Jul 31 2000 - 21:00:16 EST