Mail Bag
Mail Bag
| Thursday, January 15, 1998 |
Interestingly, most of the feedback I received on the .dll security issue related, not to how worked up we're getting about .dll security, but how we're so casual about executables:
Date: Tue, 13 Jan 1998 150132 -0600
From: "Statz, Jeremy"
Subject DLLsI feel the need to point out that a DLL is no more dangerous than the dozens of little programs and utilities you provide links to.
Seems rather bizarre that people are perfectly willing to download and run a strange EXE, yet worry about the effect of a quake dll even to the point of starting up impossible verification projects.
In short, as far as I'm concerned, provide the link and don't give it a second thought.
Just my two cents on the issue.
--Jeremy Statz
Raven Software, designer
Date: Tue, 13 Jan 1998 142614 -0800
From: "Jon M. Stokes"
Subject: Blues Mailbag DLL Security IssuesJoey Liaw's .plan brings out the main problem with .dll security issues accountability. As Mr. Liaw pointed out, shareware is usually benign because corporate reputations are at stake. If everyone knows exactly who wrote which patch, then patch authors can be held accountable for patches that harm a system.
I propose that we use code signing to handle the accountability problem. Have a central authority issue each patch author with a private key. The author uses this key to sign his code before uploading it to a site. When the user downloads the patch and decompresses it, the decompression app would read the signature and tell the user exactly who created the patch. This is a lot like the way MS handles ActiveX controls.
We could combine compression and code signing into one utility. The corresponding decompression utility could be modified to read the signature upon decompression. You could download a data file every now and then from the key authority for use with the decompression app. This would let you read whatever new signatures have been added.
The advantages to this are numerous. For instance, instead of having a central authority to thoroughly test each patch before release, you just have a central authority to maintain a key database and issue and revoke key privileges. Let the users do their own testing. If somebody writes a malicious patch, then report him and have his key revoked.
Of course this is by no means foolproof. The main problem with it would be for the key authority to determine that an applicant for a key is exactly who he says he is. If some bunghole has a habit of obtaining a key, putting out a bad patch, having his key revoked, getting a new key under another identity, etc... then this is bad.
Patch users might only end up trusting certain signatures. At least the signature method would allow patch authors who make good patches to be recognized and trusted. It would be impossible to impersonate them (unless you stole their key).
Of course you may have multiple standards bodies who obtain keys and start testing patches and issuing patches under their signature. For example, you could get patches verified and signed by one clan or another.
This code signing idea won't solve world hunger or anything, but I do think that it has quite a bit of merit and should be considered as an option. I definitely don't think it could hurt. I also don't think it would require too much effort to get going. The utilities shouldn't be hard to write, and they could even be based on one of the nice public domain zip utils for which the source is available (e.g. Info-Zip). Just pick up a good cryptography book. I recommend "Applied Cryptography Protocols, Algorithms, and Source Code in C" by Bruce Schneier.