Date: Mon, 24 Jul 2000 01:34:44 -0700 (PDT)
From: Andre Hedrick <andre@linux-ide.org>
Willfully and now knowingly issuing commands that are otherwise not listed
will be defined in ATA-ATAPI Specification can be deemed as violation of
the Standard. Regardless if there are vendor-unique commands present or
not, this would defined as accessing commands that are not considered the
standard and deemed a violation.
Andre,
I've worked with many standards bodies (I chair the IPSEC working
group at the IETF and serve on the Security Area Directorate), and
people violating the specifications happen all the time --- by vendors
probably as often as by OS's or by software programs. Violating
standards is not, as much as those of us who work on standards
organizations might wish, a felony. Hell, it's not even a
misdemeanor.
The arguments about product liability strike me as being utterly
fradulent, as does the claim that putting this filter in the OS actually
helps stability.
The simplest way to prove this is to implement your disk-destroyer.c
program as a OS-portable program which uses direct I/O access to the
IDE controller to accomplish the exact same thing. You have no idea
how tempted I was to simply write and post such a program just to make
the whole thread die. It wouldn't be hard, and after such a program
was written and publicly redistributed, the arguments that putting
such a filter into Linux would help the security of the system would
be shown to be ridiculous. It would work for all operating systems,
and in fact it would be even more trivial to use for Windows viruses,
since you wouldn't have to find root exploit first, as you would have
to under Linux first.
It might also help the T13 committee understand why firmware upload
commands MUST (in standards parlance) be protected using some kind of
public key signature --- or, if they don't want to pay RSA royalties
(which expire by September anyway), by a keyed cryptrographic
checksum. That is, the firmware should include an MD5 or SHA checksum
of the code plus a secret which is only known by the firmware loader,
which validates it. This isn't perfect, in that someone can pull
apart the controller board, and reverse-engineer the firmware loader
to get the secret key, but if every single new drive model had its own
secret key, it would probably be good enough until the RSA patent dies
its well-deserved death. (If they need any help with the crypto, I
will be most happy to help them; just have them contact me.)
The real problem, though, is that you have to be very careful how you
communicate things. By overstating the case, it actually hurts your
attempts to get people to pay attention to you. This is probably true
regardless of whether it's the kernel development community or the T13
committee. Rational, well-reasoned arguments is always always better
received by folks than WRITING IN ALL CAPS AND RUNNING AROUND SAYING
THAT PEOPLE WILL DIE UNLESS THEY LISTEN TO YOU.
Quite frankly, if you've ever behaved on the T13 mailing list the way
you've behaved on the Linux-kernel mailing list, I'd be embarassed
that you were billing yourself as the representative of the Linux
community to that committee and to the IDE industry. We need the
industry to see us as professional, and your actions were extremely
unprofessional, and perhaps even childish.
Look, just being the most technically smart isn't enough. You also
have to know how to work with people, and to also have a certain sense
of proportion. If we ship without the patch to filter out the IDE
commands, this isn't the end of the world. It may "violate the T13
specification" (does it really say MUST or does it say SHOULD?), I
assure you Microsoft has violated far worse in their day. And once
someone takes me up on my suggestion to publish a I/O port banging
routine which does what your disk-destroyer.c does, it won't make a
difference anymore. Since it will likely rapidly get merged into the
next Melissa or ILOVEYOU virus (with a *far* greater likelihood of
destroying Windows machines than Linux boxes, let me assure you), I'm
relatively confident that the T13 committee will figure out how to
issue a recommendation that drive manufacturers do a better job of
protecting their firmware upload programs.
- Ted
P.S. If someone does post such a program, it might be a good idea to
post it aonymously, via some remailer or via a anonymous USENET
posting service. This will avoid the chance of lawyers and liability
attached to posting such a program --- although in my opionion
manufacturers that release unprotected firmware upgrade paths are so
stupid and so criminally liable that they deserved to be sued into the
ground, some courts might not agree with me, and in any case,
defending against such a lawsuit would be a pain. So publishing such
a program anonymously is definitely the way to go.
P.P.S. I won't have time to write such a program, so don't bother
asking me for a copy of it.
-
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:17 EST