Messages in this thread | | | Date | Mon, 24 Jul 2000 15:04:02 -0400 | Subject | Re: Direct access to hardware | From | tytso@mit ... |
| |
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/
| |