Backdoor Found In UnrealIRCd Source Archive

l_bratch writes "A malicious backdoor was added to the UnrealIRCd source archive some time around November 2009. It was not noticed for several months, so many IRC servers are likely to be compromised. A Metasploit exploit already exists."

Comments

Only some versions affected

[jaak]

Slightly misleading summary. Only some versions on the mirrors were affected.

From the UnreadIRCd forums:

The Windows (SSL and non-ssl) versions are NOT affected.

CVS is also not affected.

3.2.8 and any earlier versions are not affected.

Any Unreal3.2.8.1.tar.gz downloaded BEFORE November 10 2009 should be safe, but you should really double-check.

Re:Remember, kids!

[Stupendoussteve]

Actually, the hash was not modified from when they posted the true source. Anybody who would have checked it would have recognized that something was wrong.

Re:Open source

[tsj5j]

Read the original linked source. The source repositories were not compromised; rather, the mirror servers were. The mirror servers had the tarballs replaced with malicious code.

Re:It's nice that they're honest.

[Lobachevsky]

Closed source software has similar problems with disgruntled employees. Only difference is that the company when finding the backdoor quietly fixes it and gags anyone from going to the media about it.

Re:Windows safer than linux

[Anonymous Coward]

No, the Windows binaries were not affected. If you compiled them, they would have been affected.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Gentoo (Linux) not affected

[miknix]

Cool, you dont get to see this too often when windows version is safer than a linux one!

Hehe..
It also depends on the distributions. Gentoo Linux, for example, was not affected because the package maintainers at Gentoo digitally sign the source tarballs. In this case, the digest created by the Gentoo developer corresponds to the uninfected version. So, any Gentoo user trying to install UnrealIRCd from a infected mirror, would have a digest mismatch and the package manager would just refuse to install.
See https://bugs.gentoo.org/show_bug.cgi?id=323691

Of course it things could still go wrong if the UnrealIRCd maintainer at Gentoo digitally signed the infected tarball. But developers at Gentoo have a lot of experience, so I suppose most everyone checks the hash of tarballs after download. At least I do..

Re:It's nice that they're honest.

[Anonymous Coward]

There is no need to audit the entire source, because the CVS wasn't affected. It is actually quite clever to put the backdoor only into release tar balls, because the "many eyeballs" that open source is famous for typically only look at the original source, i.e. the main repository.

Re:Gentoo (Linux) not affected

[Anonymous Coward]

You're wrong, read comment #8. The ebuild manifest was created using the infected version. Package maintainers are suppose to verify the source tarballs before making an ebuild which creates RIPEMD-160, SHA-1 and SHA-256 checksums. Gentoo wasn't any safer in this instance due to maintainer failure.

Re:Well yes...

[bstreiff]

Also of interest: Linux's CAP_NET_BIND_SERVICE capabilities flag, which would allow giving a process the ability to attach to lower-than-1024 ports without giving it full root.

Re:Remember, kids!

[Hatta]

That's why it's important to have GPG signed packages from your distribution. It's a shame Unreal isn't available through Debian.

Re:It's nice that they're honest.

[Zigurd]

The parent post here found the key fact: If you check article, in fact it confirms the back door was NOT in the source code. Someone replaced some mirrors, and due to lack of a signature, got away with it for a long time.

This event does not repudiate the protections of having source code available to inspect, and having project governance that reviews code. It does suggest people should be careful about which mirrors they use and how signatures are checked.

Re:It's nice that they're honest.

[GofG]

The code was not compromised. Someone swapped one of the .tar.gz's with their own, but the cvs (source) was intact. This is one of the rare situations in which being open source did nothing to help security, but the exact same thing could have happened to a proprietary application.

Re:Well

[X0563511]

I KNOW.

Please read what I wrote.

Hash a large file. Time is spent. Cryptographically sign a file, more time is spent.

Instead, you sign the hash, and spend -less- time computing the signature. If the signature is true, then the hash is true, and by extension the large file is true.