| |||||||||||||
Vsftpd backdoor discovered in source code (The H)Vsftpd backdoor discovered in source code (The H)Posted Jul 5, 2011 4:53 UTC (Tue) by danieldk (guest, #27876)Parent article: Vsftpd backdoor discovered in source code (The H)
Evans, the author of vsftpd which is described on its web site as "probably the most secure and fastest FTP server for Unix-like systems" was alerted on Sunday to the fact that a bad tarball had been downloaded from the vsftpd master site with an invalid GPG signature. Yet another reminder to check source tarballs using the signature, or preferably use a package manager with code signing.
(Log in to post comments)
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 6:21 UTC (Tue) by mbar (subscriber, #73813) [Link]
Just as seen in Gentoo :)
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 7:41 UTC (Tue) by cdamian (subscriber, #1271) [Link]
Even if you use a signed package, you have to hope that the packager checks the source fingerprint / signature every time he updates it.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 7:48 UTC (Tue) by danieldk (guest, #27876) [Link]
Indeed. A lot of responsibility rests on the shoulders of the package maintainer. But if he/she gets it right, thousands of people benefit.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 8:06 UTC (Tue) by hpro (subscriber, #74751) [Link]
One thing that strikes me every time though, is that if they compromise the server hosting the source, they should just as easily be able to change the advertised checksum on the download page? Doesn't that kind of make the checksum moot?
Shouldn't one download the source from more than one "reliable" sources and make sure they match (each other, and the checksum)?
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 8:10 UTC (Tue) by farnz (guest, #17727) [Link] That's why you want digitally signed signatures (GPG can create such things). If the maintainer is dealing with the same upstream for a while, the change of signing key is a major event, and worth cross-checking by other routes (e-mail, IRC). Even better - if upstream can get involved in the PGP Web of Trust, a change of key to an attacker's key that aims to look like upstream's key will change from a key you trust to an untrusted key, giving you a chance to intervene.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 8:23 UTC (Tue) by hpro (subscriber, #74751) [Link]
Digital signatures within your Web of Trust are very nice, but realistically, you usually only have a checksum next to the download link when you are downloading the source for some project yourself.
But then again, in the end you might just be downloading a program that is malicious to begin with, and no checksums can help you with that. (E.g., Android Market)
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 9:37 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Verifying an OpenPGP detached signature would be more reliable for package maintainers though since they would quickly develop a history. It's the same rationale as web browser add-ons that alert you when the SSL cert for a site you visit _changes_ on the basis that it's far more likely bad guys will attempt a MitM attack somewhere between your 1st and Nth visit than before the 1st visit.
This seems like it's worth building into package building automation. "Download new source" should be "Download, verify as authentic and refuse to continue if not" for every package that provides detached signatures. This would require explicit intervention if the author (or rather signer) changes, but that is a significant event of which the maintainer certainly should be aware.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 13:04 UTC (Tue) by drag (subscriber, #31333) [Link]
Plus it's very important to make sure that the servers that have the hash/signature/keyrings are going to be different from the ones that manage the packages.
You don't want one server compromise allow the attacker to not only upload his own package, but sign it also.
Putting the signature in URL would force them to break links Posted Jul 5, 2011 11:48 UTC (Tue) by gmatht (guest, #58961) [Link]
I was thinking if you put the signature in the url it would create much lulz if people looked for the package by following an external link. :) It would be quite easy to create a file type .sha256chk, and associated utility that when given a file called X.Y.sha256chk renames it X if the file matches the sha256sum Y. This notation would also help when you are trying to chase down a broken link like http:.../README; a websearch would find thousands of unrelated README's but hopefully only one "README.0983e91e1f8a061385f41464e141c94892f0f3ccc8e0d5a5167f1841c0f123c4.sha256chk".
A variant could also be to let Y be a tinyurl like reference to a public key, and the whole filename stored in a public mirrored database linking filenames to signed sha256keys, so even the author cannot re-release a file with the same name.
Putting the signature in URL would force them to break links Posted Jul 6, 2011 20:19 UTC (Wed) by zooko (subscriber, #2589) [Link]
Hey that's a good idea. A base-62 encoding could make the results more compact, e.g. your example would then look like:
README.2FtSwvET66qZj2xqQjlAi6VFYW4ZQfCRhFgc3fwMglg.sha256chk
instead of:
README.0983e91e1f8a061385f41464e141c94892f0f3ccc8e0d5a5167f1841c0f123c4.sha256chk
Putting the signature in URL would force them to break links Posted Jul 6, 2011 21:06 UTC (Wed) by Tov (guest, #61080) [Link]
Wouldn't base62 encoding create problems in case-insensitive environments (e.g. when stored on a FAT filesystem)?
I would rather sacrifice a bit longer filenames for robustness and human readability (when comparing hashes).
Putting the signature in URL would force them to break links Posted Jul 6, 2011 21:41 UTC (Wed) by zooko (subscriber, #2589) [Link]
Yeah, you're partially right about case-insensitive filesystems like VFAT or NTFS. Actually nothing would go terribly wrong on such a filesystem except that the chance of collisions would be less astronomically unlikely. However, it still smells a bit icky to have only astronomical collision-resistance instead of super-duper-astronomical collision-resistance, depending on your local filesystem.
Also you're right that base-62 is harder to read aloud than other encoding (because you have to say "uppercase" and/or "lowercase" a lot). An alternative that addresses these two issues is base-32, e.g.:
http://pypi.python.org/pypi/zbase32/
rationale for zbase32 versus RFC 4648:
http://tahoe-lafs.org/trac/zbase32/browser/trunk/zbase32/...
On the other hand the more compact result of base-62 makes it a little easier to cut and paste, which is probably more common than reading aloud nowadays.
Here are the examples again.
base-16 (hex):
base-32 (zbase32):
base-62 (zbase62):
|
|||||||||||||