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
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.
My guess is that it's not like Windows users would ever want to compile something manually when there's an installer out there for it, and the perpetrators probably didn't feel like going through all the effort to build the backdoored version for Windows when no one in their right mind hosts an IRCD on a Windows machine.
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.
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).
Comment removed based on user account deletion
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.
the more efficient way is to sign the hash.
Digital signatures actually ARE signed hashes. So I'm not sure what you're trying to invent there (and how it would be more efficient).
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!
When did Debian and it's Free Software Guidelines become the required standard for open source. Oh, wait, it didn't.
Not every distribution uses apt, so not being in apt is not being less than open. Quite the reverse is true. By limiting themselves to apt, they are being less open.
So, what you are implying is that a standardized software packaging system, the creation of which flossies have fought tooth and nail because it would make things less free, is the way to go, but only if it is the system you prefer.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
If you want to use a hash alone, you only check integrity, but not authenticity. The attacker may alter the hashes published on your server and you won't detect that.
And again, if you meant signed hashes, then that is exactly what digital signatures are. Signed hashes of the files. The recipient hashes the file, compares the hashes, and verifies the signature of the hash. That's how digital signing works, my friend.
Your posts contain no suggestions for improvement, but they may even weaken your security.
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...