[lkml]   [2000]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: disk destroyer, etc
    In <Pine.LNX.4.21.0007240239040.12536-100000@tricky> Bartlomiej Zolnierkiewicz ( 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:
    > "
    > []# ./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?

    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.


    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.045 / U:3.712 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site