Popular FTP package download tarball poisoned

A backdoor has been discovered in the source code of a widely used FTP package. Version 2.3.4 of the source code for vsftpd – billed as probably the most secure and fastest FTP server for Unix-like systems – was replaced with a compromised version with an invalid signature. The dodgy tarball version of the code was uploaded …

[Ryan Robinson]

Lulz?

"Therefore, perhaps someone was just having some lulz instead of seriously trying to cause trouble."

Tampering with a piece of software that handles the logging into FTP servers to edit websites and web apps is actually malicious and should be treated seriously. For all we know the code could have been hijacking the credentials being used on the infected client.

[fourth of three]

How many would check?

"it is unlikely that too many of the tech-savvy users of vsftpd fell victim to the hack. "

Wc reports >16k lines in the source files. Fairly compact but how many are going to look through them before invoking make?

Even if you wrote "Please note that this distribution contains malicious code" in the INSTALL file, I doubt that few would notice. This is human nature.

[Chris Miller]

Unsigned

But it sounds as though it would have failed a signature check.

[Robert E A Harvey]

md5

So you never check the independent MD5 checksum then? Or did they hack that too?

[Flocke Kroes]

After a while, checking is easy:

The magic command is:

gpg --verify downloaded.tar.bz2.sign

If downloaded.tar.bz2 does not match the signature, gpg will scream. If the signature matches, but was not made by a key you have previously marked as trusted, gpg will scream.

Newbies will start with an empty list of trusted signatures. A simple way to get started is to download everything, then wait a month or two for reports of bad signatures to hit the news. If there is no news then you can have some confidence that you downloaded trustworthy public keys.

[Anonymous Coward]

Published Signatures

The signature that is published on the website along with the download would be under the control of the attacker.

Signature checks only make sure data is not changed in transmission

[Anonymous Coward]

Signature not checksum!

Everyone else is talking about public key cryptography signatures not mere hashing checksums.

Signatures require signing with private keys. Obviously, getting access to a private key is non-trivial, even for the best hackers. This is kind of the point ...

[Rob - Denmark]

Lul while you can!

Som much for the test, or POC if you will.

Now we can just wait for the real deal, with fake signature and all.

[Destroy All Monsters]

This

"Nonetheless the incident illustrates that code repositories can be poisoned and the importance of checking digital signatures as a safeguard against falling victim to such shenanigans."

You cannot check for E.Coli in German Sprouts, but you CAN check the signature.

[Rob - Denmark]

Who knew?...

There are signatures in German Sprouts?

[JEDIDIAH]

No signatures with sprouts.

This is why all of my Spinach is now buttered London pub style now...

[John Robson]

Check against???

The string on the same page (which has therefore by definition been compromised)?

A public key also stored on the same page?

Why aren't the keys checked by a package manager (how most people install these things)? Why aren't they in some way securely distributed (DNSSEC hosted?)

[Daniel 1]

And why wasn't he using Tripwire

It's a code repository, after all. Tripwire would have told him the moment any file there was touched. Three days seems a long time, to me.

[Steve Murphy]

Check against???

"The string on the same page (which has therefore by definition been compromised)?"

The signature needs signing by a trusted key which was not compromised - that is kind of the point.

[jubtastic1]

Hypothetically speaking

If say you had (by fair means or foul), root access to a popular FTP server, and you noticed from the logs that a lot of interesting users were using outdated versions of vsftpd, and you had a way of notifying those users to update, in the welcome message for example, then a headless hack like this takes on a whole new aspect.

Simply assuming that someone would go to all the trouble of poisoning a source depository just for the lols is a bit unimaginative.

I would be looking for the FTP servers that respond with :) in their handshakes personally, that might give us a clue as to what's going on.

[Anonymous Coward]

Just having 'lulz'?

Try walking through a security checkpoint at an airport and casually say something like "Gee, I hope Abdul remembered to take that bomb out of my laptop!"

Then say "I was just saying that for the lulz!"

See how far it gets you.

Mucking around with repositories is always a serious security attack - after all, this might have just been a test run...

[Scorchio!!]

Re: Just having 'lulz'?

"Mucking around with repositories is always a serious security attack - after all, this might have just been a test run..."

Somewhere else I raised the possibility that repositories could become compromised and people shouted this down.

[qt101]

MD5 hashes Pplz ;-)

Run the hash; for Checksum changes; doing MD5 hash comparison would have given away any nasty re-packing efforts.

I run the Hash check on everything I download. There's many neat little programs/apps you can use to do these checks.

You can't loose; Always match MD5 to check for file changes.

[Benedict]

You can't lose

unless the source of the hash has been compromised too.

[Eddie Johnson]

Or was never right in the first place

Or you start getting lots of false positives because people fail to rigorously post their updates and hashes together. The kind of companies that are constantly posting a stream of bug fix versions are the very ones that also manage to screw up the hashes a decent percentage of the time - because they are too lazy to check themselves.