In case you haven't yet heard, the venerable ProFTPD code has been compromised, according to this posting:
On Sunday, the 28th of November 2010 around 20:00 UTC the main distribution server of the ProFTPD project was compromised. The attackers most likely used an unpatched security issue in the FTP daemon to gain access to the server and used their privileges to replace the source files for ProFTPD 1.3.3c with a version which contained a backdoor.
This isn't the first time, and it won't be the last time, unfortunately. Reading on in the report, I stumbled over a few lines which I've seen countless times:
The MD5 sums for the source tarballs are: 8571bd78874b557e98480ed48e2df1d2 proftpd-1.3.3c.tar.bz2 [...]
$ md5sum /etc/passwd 4732518c5fe6dbeb8429cdda11d65c3d /etc/passwd
These sums are typically put up on a Web site for you to verify
against the downloaded file. So, if you do verify the sum, and I strongly
doubt that most people would, you retrieve the file, calculate its MD5 sum and
compare that sum to the number you found on the Web site. That is all very
fine and dandy, if -- and only if, you trust the Web site hasn't been
compromised together with the file you just downloaded. In addition to all of
that, you have the PGP or GnuPG keys you can use to verify the download, but I
doubt even more that people do this on a regular basis. (You know the deal:
tar xvzf; .
make; no time for much verification
there...) So the question I ask is: can I trust the MD5 sum I see on the Web
site? If, and this is just an idea, I trust the signed DNS for the site,
then surely I can trust an MD5 hash published via the DNS, can't I? With
DNSSEC getting here slowly but surely, we have a mechanism to distribute
small blobs of data securely. So, why not distribute the MD5 hashes of files
via the DNS? DNSSEC to be precise? I know, I know: you'll all be saying:
what??? Another bit of data in the DNS? What else should it carry? It contains
CERTificates, SSH fingerprints, and what not, and now file MD5s?
Sure, why not? And to add insult to injury, I'm going to suggest publishing
those as a TXT resource record. Oh, no!, not another TXT format? Pourquoi
pas? See RFC 1464 for some more neat ideas... :-)
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1 ;; ANSWER SECTION: proftpd-1.3.3c.tar.gz.example.net. 120 IN TXT "4f2c554d6273b8145095837913ba9e5d"
For the benefit of those of you who haven't noticed, let me point out
the two letters
ad in the first line of the output above: Authenticated
Data. This DNS server has confirmed that the TXT record has been authenticated
by whoever manages the
example.com zone. Now I don't propose to construct
the domain names like in the example above. Probably something along the lines
of "remove all punctuation marks" in the package name, and tack on
".md5.example.net" to query the DNS for a TXT RR. Thoughts? So what, if the
DNS server is on the same box? The important thing is that the DNSSEC
signing keys aren't on that box.