Backdoor Found In UnrealIRCd Source Archive 174
Posted
by
timothy
from the channel-is-pwn3d dept.
from the channel-is-pwn3d dept.
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."
Only some versions affected (Score:2, Informative)
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! (Score:5, Informative)
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 (Score:5, Informative)
Re:It's nice that they're honest. (Score:4, Informative)
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 (Score:1, Informative)
Re:It's nice that they're honest. (Score:5, Informative)
"It appears the replacement of the
2 as far as exploit goes, this is pretty limited:
"This backdoor allows a person to execute ANY command with the privileges of the user running the ircd. The backdoor can be executed regardless of any user"
- who is actually running a irc demon as root?
3 IT WAS NOT IN THE SOURCE
"CVS is also not affected."
- they substituted the archive
Re:Gentoo (Linux) not affected (Score:2, Informative)
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 [gentoo.org]
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. (Score:1, Informative)
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 (Score:2, Informative)
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... (Score:2, Informative)
Also of interest: Linux's CAP_NET_BIND_SERVICE capabilities flag [kernel.org], which would allow giving a process the ability to attach to lower-than-1024 ports without giving it full root.
Re:Remember, kids! (Score:3, Informative)
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. (Score:5, Informative)
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. (Score:2, Informative)
Re:Well (Score:3, Informative)
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.