eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The compromise of the WordPress 2.1.1 distribution code on its own servers got me thinking about the weaknesses of code distribution security as a general matter. The subject didnt originate with this attack, although it is a stirring reminder of how serious it can be.
On most platforms a distribution file is accompanied by a separate file containing an MD5 hash. Youre supposed to download both, run the hash on your side and compare it to the hash you downloaded and this proves … what? It certainly proves that the file wasnt corrupted after creation or in transmission, like a CRC back in the days of XMODEM and bulletin boards. But if I can hack into your site and change your file, surely I can create a new MD5 hash file reflective of my version of the file, so checking the MD5 hash doesnt say anything about the integrity of the file.
A better solution would be based on digital signatures, where you could check the publishers public key to see if the file was modified. So how would it work? Heres my first shot at some rules, lacking the sort of consideration that will come as we write up the RFC. Lets call it “Simple File Signing” for now.
The publisher (lets use WordPress as our example) uses a private key to sign a file that users may download. I envision most people using the OpenSSL command line tools to do the PKI (public-key infrastructure) parts of this process. This generates a signature that they put in a file in the same directory as the file that they signed, much as with an MD5 hash. Users download both files.
How do they get the public key to check the signature? The best option here is through HTTP on a special high-number port. (I propose port 5397, which spells “keys” on a telephone.) The specifics of what an HTTP (actually, its probably better to do HTTPS) GET request returns are not important at this point, but they will probably consume the bulk of the time in defining a standard. Lets get back to it in a minute.
In the meantime, in order to check a signature, the client system has to know what domain to check with and how to find the signature file. The default domain to check should be the one from which the file was downloaded, but you should be able to specify a different domain. I suggest prefixing the domain name to the file name. The latest version of WordPress, for example, seems to be at http://wordpress.org/latest.tar.gz. If I were to host this file on eWEEKs site I might name it www.eweek.com/wordpress.org.latest.tar.gz in order to specify that the PKI check should be performed on wordpress.org.
But I would also have to host the signature file, which I suggest should have the same file name with a .sig extension. So my copy of the signature file for WordPress would be named www.eweek.com/wordpress.org.latest.tar.gz.sig.
The simplest version of this system would then have the client system do an HTTP/HTTPS GET from wordpress.org and retrieve a public key. But there is so much more interesting and useful work that can be done between the two systems that it makes sense to enable a two-way conversation, probably through an XML vocabulary. Thanks to Andrew Jaquith, an analyst at the Yankee Group, for pointing out that there is a standard in this space already: XKMS 2.0 (XML Key Management Specification) from the W3C. I havent studied it yet—its a pretty big Web page.
Consider the example of the private key becoming compromised: The publisher would want to convey that information immediately, and a sufficiently rich key retrieval system on port 5397 can do that. It can return a result that says that the key you are requesting belongs to a pair that was compromised and should not be used. In a different example the response might be to return the key and point out that a newer version of the file, with new signatures, exists. In either example the response could include a link to a new version.
Operations like this are always possible through manual twiddling in telnet, but the reality of this process for nearly everyone will involve a Firefox or Internet Explorer extension. Theres no reason why it couldnt be implemented in FTP clients as well.
Next page: A simple and open standard.
A simple and open
standard”>
I see this idea as being much in the tradition of OpenID, in that it solves a real-world problem in a very simple way. It should be extremely easy to implement, depending on how involved we get with the XML stuff. XML specifications often seem to get out of hand.
Its also in the tradition of OpenSSL, a program that made secure Web sites available to masses. Prior to OpenSSL, creating a secure Web site was an expensive process. Now, thanks to this free and open-source program, anyone can do all the basic PKI work. As Ive already said, OpenSSL will likely be the common way to implement the PKI behind Simple File Signing.
Im not the first to think of using PKI for file authentication. Microsoft long ago got sophisticated—perhaps too sophisticated—about this problem and created Authenticode, a digital signature system in which the file contains a signature that can prove that the file was not tampered with and shows the name of the publisher of the file, based on the certificate.
The trust in the Authenticode system rests in very large part on that publisher name. Microsoft has tools you can use to make your own certificates, and of course you could use them to create certificates that say you are “Microsoft Corp.,” so that alone of course is not trustworthy.
The missing piece of the puzzle in Authenticode is that you need, for all practical purposes, to use a code-signing certificate issued by a trusted certificate authority, such as VeriSign. VeriSign does verify the identity of the organization buying the certificate, so I cant buy one that says Im Microsoft.
This system works really well, as designed, but there are two problems with it: Code signing certs are expensive—hundreds of dollars per year—and they need to be in order for CAs (certificate authority) like VeriSign to do the verification they do. Also, the company name can be somewhat ambiguous as a trust marker. See this old column of mine for an example of a sleazy developer slipping misleading company names through the literal requirements of the program. But I think the cost issue is the far more important one.
Also like OpenID, which has some excellent opportunities for spoofing, Simple File Signing is likely to be attacked. Im sure there will be attacks on the basic PKI, but whats more obvious is phishing. For instance, its not hard to see e-mails offering www.yes-we-really-are-paypal.com/yes-we-really-are-paypal.com.security-update.exe and an appropriate .sig file. The owner of that domain can set up keys to authenticate the malware he is pushing and it will come through as OK.
Remember, authentication isnt the same thing as trust. In this case, user would trust the file in part because they see and trust the domain name, which is central in Simple File Signing. The answer is for Simple File Signing clients to display the domain name prominently and, after doing a whois on it, the owner of the domain as well. This should raise the alert level for most people.
Clearly the system isnt perfect, but I think its a very useful one and has the potential for quick and wide implementation. Its worth pointing out that the key distribution system is not just useful for file signing. Inevitably other applications for it will come along. Perhaps the web server end of the system will become a standard component for Apache and IIS.
PKI has always been an underachieving technology because of high barriers to entry for cost and complexity. Simple File Signing can enable new growth for it where it is needed most.
In addition to Andrew Jaquith, Id like to thank John Levine and especially Paul Hoffman of the Domain Assurance Council, who listened to me and provided great feedback. Im sure Ill be working with them more in the future on this.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.