Slashdot Mirror
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."
This is the kind of behavior that I like to see when someone screws up. Don't be secretive. Don't try to deny it happened. Fess up and make sure people know. *applauds*
Restore the madness of youth's lechery
From TFA "The Windows (SSL and non-ssl) versions are NOT affected."
Cool, you dont get to see this too often when windows version is safer than a linux one!
I'm not quite sure how that would help as this was built directly into the source so the official blessed hash that you are comparing against is compromised.
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.
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.
FTA, "Obviously, you only need to do this if you checked you are indeed running the backdoored version, as mentioned above."
A skilled attacker will have replaced md5sum so that it returns the hash that corresponds to the good version, and in general installed a rootkit. The remediation advice they provide is broken.
If you have installed the affected software, you should probably assume you are owned, regardless of what any local tests tell you.
How is it a weakness? It's a weakness of the admin, but being open source didn't somehow make it easier to get malicious code into the source. People could just as easily hijack a binary file (and there's a good chance it would go unnoticed for a longer time).
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.
From the post in the forum, it seems that only the source tgz in the mirrors was affected. So, anyone who checked the MD5 agains the official (non-mirrored) tgz would realize the difference.
Apparently, no one bothered to check for a long time, though.
I'm implying that anyone who manages to get commit rights, or even a contributor who's good as obfuscating code, could implant a backdoor into a project. Remember the Debian SSL fiasco? Well, that sort of thing could happen maliciously. In a closed source development environment it's harder (note, I didn't say impossible) to get this sort of thing in, as the effort and/or expense required to inject a mole into the developer circle is higher and the personnel are typically more carefully vetted.
However, the strength of open source is that there are many people looking over each others' shoulders. In a closed source environment, if you manage to get your mole into an area of code development where there are only a small number of developers, well-hidden and obfuscated malicious code could stay buried potentially forever, as once those few guys move on (and they will in corporate land), nobody who comes after then will aggressively pursue legacy code as they won't want to break anything that's already working. Nothing short of a full code audit will catch it.
And thank you for making me explain myself in full.
I hate printers.
Haha, nobody ever checks hashcodes. It's only a matter of time before like 10 million users install something and NONE of them checked the hash code !
Apparently, no one bothered to check for a long time, though.
Or perhaps the people that did check just assumed that the genuine uploaders forgot to include/update the hashes so that the difference was due to the hash being for the previous (or earlier) version. Though in that case you'd expect the sort of person who would check official hashes would be the sort who would report the discrepancy upstream (or at least ask about it on an official forum).
Just because you have a MD5 signature, does not mean it's any good. Always verify the PGP signature.
According to some reports that were made by people on IRC Security related discussion forums:
First, as others have said, the Unreal guys handled this intelligently and properly, so bravo for that.
Secondly, no offense to them, but the Unreal guys wouldn't have had this issue if they regularly verified mirrors. The Unreal guys have been less active in the past few years though, and their software is primarily used by many smaller networks, often with less experience as the IRCd is a bit slow and the codebase is long in the teeth (they're looking to replace this). Something like this was really bound to happen for their team. That said, still good work.
Thirdly, this is why IRC is never ran on its official low numbered port, but on 6667 - there is NO REASON to run IRCd as root - I don't care how safe you think the code is - it's too huge of a target.
So hopefully, anyone sane shouldn't have had more than a sandbox compromised, the patch the Unreal guys released will fix this, and we can all get on with stuff.
Just a few thoughts, oh, and IAAI and IAAIP (I am an IRCop and I am an IRCd Programmer).
From the post in the forum, it seems that only the source tgz in the mirrors was affected.
Fair enough, the site was /.ed when I looked so I wasn't able to glean that information
Yet another reason to digitally sign your packages. That way, even if your server is hacked, people will know it didn't come from the authors of the software.
See gnupg.org
Comment removed based on user account deletion
That's what I like about open source. Eventually things get found out.
Keep Doing Good.
This wasn't commit rights.
This was attacking the mirrors.
You can do the same exact thing to closed source software, by infecting the binary with a malware installer.
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..
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.
This is one of the reasons I do not 100% trust a package manager. Sure, it is more secure than downloading from a random site, but there is very little stopping an upstream security issue (or even malicious author) from making it into the mirrors, and I don't trust that all distro developers are checking that the hashes match either.
There's really no technical excuse for not catching a deviation between a release point in a VCS system and the associated tarball, assuming the VCS hasn't also been compromised.
Given this statement, the sensible eyeballs are validating the source as it exists in the VCS, and the sensible admins are checking the correspondence of the tarballs downloaded against the associated VCS checkout checksum. I'm not saying this is the procedure most sites us, just that there's no conceptual obstacle to making this happen. The locus of trust is the VCS system, not the derivative tarballs.
It's the stupidest thing I've heard in a long time to think that open source has such a surfeit of competent eyeballs that they can afford to scatter their resources and catch deviations everywhere, including purportedly identical copies.
That's putting a value of zero on a competent eyeball. Competent eyeballs are contributing to the project, and noticing defects on an incidental basis. This incidental attention catches a lot where activity is heavy.
Vandalism on obscure Wikipedia pages often survives for months, if more subtle than replacing the entire page with
$favorite_underutilized_part_of_my_anatomy!
The concept of scattering this kind of precious scrutiny over derivative works because software installers are too damn lazy to check the shasum boggles my mind.
I end up installing quite a lot of software in the middle of trying to complete a complex task under deadline. Many times I've closed my eyes and typed "sudo make install". When I'm less under the gun I'm more deliberate in my approach. Apparently my faith in distributed paranoia is largely unfounded.
Or maybe the people setting up IRC servers have some dim thought in the back of their minds "maybe I'll meet a chick and get laid someday". There's nothing like the mating reflex to dampen the precautionary spirit.
Proposed warning for the download page:
The bad news is that this software won't help you get laid. The good news is that if you neglect to check the shasum, you might catch a vicarious STD anyway.
That's why it's important to have GPG signed packages from your distribution. It's a shame Unreal isn't available through Debian.
Give me Classic Slashdot or give me death!
I once downloaded an open source project, checked the hash and found it was bad. Wrote the admin about it and NEVER got a response. Anybody else seen this or had a hash not check out? I can't remember what it was.
... comes greater responsibility and watching.
I hope they learnt their lesson. And other open source code maintainers, before it happens them.
This indeed happened to only the mirrors, but was pulled off by exploting the fact that the source code was open.
It's very important to keep these things under check because it's pretty much the #1 vulneraibility to this development model.
Beware: In C++, your friends can see your privates!
Here come the people screaming about how this proves Linux and open source aren't any more secure bla bla bla. Linux is not invulnerable. No OS is or ever will be. However, so long as Linux infections are so rare that each one that appears makes headlines, I will feel much more secure using it as opposed to Windows. This is the second Linux infection I have heard of in the last year or two. Compare that to the countless hoards of Windows malware we see every day. Is is only because Windows systems are far more common? Probably. Do I care? No. Why should I? Desktop Linux will likely never see the same market share that windows has, and that is just fine with me. Any kind of mono-culture is asking for trouble no matter what OS it consists of.
I always check has codes. Not that they aren't relatively easily worked around, considering most developers are still using MD5.
"City hall" in German is "Rathaus" Kinda explains a few things......