Weekly Edition
Return to the Security page
| |||||||||||||
Vsftpd backdoor discovered in source code (The H)
The H reports
that the vsftpd download site has been compromised and version 2.3.4
contains a back door. "The bad tarball included a backdoor in the
code which would respond to a user logging in with a user name ':)' by
listening on port 6200 for a connection and launching a shell when someone
connects." Anybody who downloaded and installed that version should
be looking to replace it quickly.
(Log in to post comments)
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 3:35 UTC (Tue) by tetromino (subscriber, #33846) [Link]
As far as I can tell, Gentoo users at least are not affected; the vsftpd source tarballs from Gentoo mirrors don't have the backdoor code.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 4:53 UTC (Tue) by danieldk (guest, #27876) [Link] 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.
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):
Who still uses FTP, for anything? Posted Jul 5, 2011 8:19 UTC (Tue) by dion (subscriber, #2764) [Link]
Why are there still people using FTP in the world?
There are so many less brain dead and much more secureable alternatives that it boggles the mind that anyone even knows that FTP ever existed.
I guess there are tons of unmaintained legacy systems that use FTP, but those are the sorts of people who are still happily running rsh and telnet.
Who still uses FTP, for anything? Posted Jul 5, 2011 8:39 UTC (Tue) by anselm (subscriber, #2796) [Link] This is really neither here nor there. The same type of back door could just as easily have been added to a web server, SCP server, or anything, given access to that project's distribution site. This is not an FTP-specific protocol security problem it's an infrastructure security problem.
Who still uses FTP, for anything? Posted Jul 5, 2011 8:41 UTC (Tue) by DG (subscriber, #16978) [Link]
I know quite a few web designers who only know how to upload 'stuff' over FTP. It's one of those legacy things....
Who still uses FTP, for anything? Posted Jul 5, 2011 9:01 UTC (Tue) by Cato (subscriber, #7643) [Link]
You can easily run FTP over SSL, so it's no worse than HTTPS: http://en.wikipedia.org/wiki/FTPS
Who still uses FTP, for anything? Posted Jul 5, 2011 9:30 UTC (Tue) by jengelh (subscriber, #33263) [Link]
FTP(S) is worse than HTTP(S) with regard to NAT gateways (which, I agree, should not exist in the first place ;-).
Who still uses FTP, for anything? Posted Jul 5, 2011 12:41 UTC (Tue) by silmaril (subscriber, #52105) [Link]
Well NAT is bad anyway, but FTP/FTPS doesn't help statefull firewalling neither...
Who still uses FTP, for anything? Posted Jul 5, 2011 13:10 UTC (Tue) by drag (subscriber, #31333) [Link]
> Why are there still people using FTP in the world?
Because it is convenient and it works.
> There are so many less brain dead and much more secureable alternatives that it boggles the mind that anyone even knows that FTP ever existed.
There are alternatives, but not terribly suitable replacements. The closest is probably webdev.
If you care about security you use signed/encrypted files and throw away user accounts that have nothing to do with unix accounts.
Who still uses FTP, for anything? Posted Jul 6, 2011 10:54 UTC (Wed) by Jonno (subscriber, #49613) [Link]
I'd say that the most suitable replacement for ftp would be sftp.
sftp is a file transfer protocol built on top of ssh (technically you ssh into a machine and run /usr/lib/misc/sftp-server instead of your shell), and has nothing to do with ftps (which is regular ftp within a tls channel).
sftp's biggest disadvantage is that it shares / by default, and while restricting that is easy, you also restrict your regular ssh session at the same time, making it virtually useless. Of course, you can run two instances of the ssh server at different ports, one chrooted and only allowing sftp, and one only allowing admins to log in but giving full ssh access.
Who still uses FTP, for anything? Posted Jul 6, 2011 13:22 UTC (Wed) by niner (subscriber, #26151) [Link]
If you don't restrict a regular ssh session the same way as sftp, then the restriction is useless anyway. If sftp is restricted to a certain directory, and a shell isn't, then I simply use the fish:/ protocol in KDE which simply uses basic shell commands on the server side, e.g. ls and cat. With that one can do all the things possible with sftp.
Who still uses FTP, for anything? Posted Jul 7, 2011 11:52 UTC (Thu) by Jonno (subscriber, #49613) [Link]
Of course, but my use case is one where every user can access files in a subtree, but only admins can get a shell.
If you want admins to see the same url view for sftp (which is simplifies support enormously), you need two sshd daemons on the machine, which is quite complex to set up properly (need to hack initscripts), and the admins need to remember to supply a non-standard port number every time they want to get a shell.
Being able to configure a chroot path for sftp-sessions only would simplify this hugely.
Who still uses FTP, for anything? Posted Jul 6, 2011 16:07 UTC (Wed) by jond (subscriber, #37669) [Link]
What about anonymous FTP?
What about legacy client software lacking sftp support?
Who still uses FTP, for anything? Posted Jul 7, 2011 7:25 UTC (Thu) by rqosa (subscriber, #24136) [Link] > What about anonymous FTP? Assuming that the anonymous users aren't allowed to upload files, HTTP should be a suitable replacement.
Who still uses FTP, for anything? Posted Jul 7, 2011 10:35 UTC (Thu) by anselm (subscriber, #2796) [Link] Kinda, sorta as long as you don't rely on FTP features such as partial downloads, wildcard-filename downloads or translation of line endings for text files. Of course there are ways of getting these sorted on an HTTP server, but they may involve added inconvenience for the downloading user or the server operator. For example, an FTP server will give you a directory listing but an HTTP server usually won't (not as long as you don't enable it explicitly, and then usually in an HTML format that programs must laboriously parse).
Who still uses FTP, for anything? Posted Jul 7, 2011 12:04 UTC (Thu) by Jonno (subscriber, #49613) [Link]
You know, FTP doesn't give file listings in a fixed format either, but as a plaintext file, which the client must parse differently depending on what FTP server you are running, and sometimes based on the LC_xxx settings on the server...
The closest thing to a standard there is is "do like POSIX `ls -la`", but that is not universally followed, especially by ftp servers on non-POSIX hosts...
For HTTP there is at least webdav, which can provide a standardized machine parseable directory listing...
Who still uses FTP, for anything? Posted Jul 8, 2011 7:53 UTC (Fri) by rqosa (subscriber, #24136) [Link] > partial downloads HTTP supports that, by way of the "Range:" request header. > translation of line endings for text files That really shouldn't be necessary anymore, since many programs (text editors, etc.) support the multiple different line-ending types. (And of course it will corrupt binary files if turned on by mistake.)
Who still uses FTP, for anything? Posted Jul 8, 2011 8:02 UTC (Fri) by rqosa (subscriber, #24136) [Link] (I should have linked to the HTTP/1.1 RFC instead.)
Who still uses FTP, for anything? Posted Jul 8, 2011 11:47 UTC (Fri) by union (subscriber, #36393) [Link]
I always use sftp where I can.
But ...
I find one of the major shortcoming of OpenSSH sftp implementation is lack of logging.
I believe OpenSSH devs say that since you can login via ssh and copy paste data it would not guarantee completes and provide false sense of security.
But I would like an option for running sftp only with nice logs, but as far as I can tell there really isn't any widely deployed sftp only server for linux.
Who still uses FTP, for anything? Posted Jul 8, 2011 17:06 UTC (Fri) by erwin@andreasen.org (guest, #51369) [Link]
How nice logs do you need? On the OpenSSH 4.3p2 as deployed in RHEL 5 you can enable logging by setting:
Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO -f AUTHPRIV
in your sshd_config. That will be fairly verbose (logging e.g. what directories are opened to find a file list) but will also log file transfers.
Who still uses FTP, for anything? Posted Jul 9, 2011 3:08 UTC (Sat) by VelvetElvis (guest, #69142) [Link]
I run a proprietary web application whose developers require FTP access to provide support.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 8:58 UTC (Tue) by nix (subscriber, #2304) [Link]
Not everyone who downloaded that version is vulnerable. I downloaded it on Apr 17, and it was not backdoored then.
I suspect this is a pretty recent thing.
On the subject of 'good vulnerability notices', <http://scarybeastsecurity.blogspot.com/2011/07/alert-vsft...> must surely count.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 9:14 UTC (Tue) by solardiz (guest, #35993) [Link] My analysis suggests that the backdoored tarball was on the official site for 2 to 3.5 days before being noticed and removed.
Vsftpd backdoor discovered in source code (The H) Posted Jul 5, 2011 10:13 UTC (Tue) by nix (subscriber, #2304) [Link]
Sounds like software like this needs a daily cron job on a networkologically-local site that downloads the tarball and checks it against a locally-stored signature. Not hard if you run the download site, really hard if you don't (or you waste bandwidth downloading the whole tarball over the internet daily, probably a price worth paying for something as small and exposed as vsftpd, probably not a price worth paying for something as huge and full of holes as firefox).
|
|||||||||||||