Backdoor Found In UnrealIRCd Source Archive

← Back to Stories (view on slashdot.org)

Backdoor Found In UnrealIRCd Source Archive

Posted by timothy on Saturday June 12, 2010 @05:28PM 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."

174 comments

It's nice that they're honest. by allaunjsilverfox2 · 2010-06-12 17:34 · Score: 5, Insightful

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
1. Re:It's nice that they're honest. by Abcd1234 · 2010-06-12 17:36 · Score: 3, Insightful
  
  Well, unless you're Google, in which case you're raked over the coals and accused of being at the right hand of the devil himself...
2. Re:It's nice that they're honest. by davester666 · 2010-06-12 17:43 · Score: 5, Funny
  
  It could be worse... You could be the guy at Microsoft that was ordered to write this exploit and then insert it into the codebase without getting caught.
  
  --
  Sleep your way to a whiter smile...date a dentist!
3. Re:It's nice that they're honest. by poppycock · 2010-06-12 17:47 · Score: 1
  
  Well, perhaps it was an inside job...
4. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 17:47 · Score: 0
  
  Paranoid much?
5. Re:It's nice that they're honest. by Lobachevsky · 2010-06-12 18:38 · 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.
6. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 18:39 · Score: 0, Offtopic
  
  if you are referring to google collecting wifi data, google has no credible defense. grab a linux distro, mapping ssid is a matter of a 3 lines script. If they bothered to use more code, some evil is involved.
7. Re:It's nice that they're honest. by the_womble · 2010-06-12 18:39 · Score: 1, Interesting
  
  Yes, because a single trojan in a server that:
  1) no one uses (not a single user checked the hash of the download over seven months),
  2) is not in the repos of most distros,
  3) was not included in the Debain repos, despite there being a willing maintainer, because of poor code quality- see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130
  completely refutes all the different arguments in favour of open source (many eyeballs, multiple vendors to provide free market competition, no lock in, etc).
  We all know that not one single proprietary app has ever had a security issue.
8. Re:It's nice that they're honest. by Vahokif · 2010-06-12 18:58 · Score: 2, Insightful
  
  It's still an embarrassment for open source though. In theory this sort of stuff shouldn't happen because "everyone can see the source", and if it does, it shouldn't take seven months to fix.
9. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 18:59 · Score: 2, Insightful
  
  Yes, because a single trojan in a server that:
  1) no one uses (not a single user checked the hash of the download over seven months),
  The hashes most probably _where_ checked by peopel, however they've been changed to reflect the backdoored .tar.gz on the website.
  This is from the horses mouth a.k.a. Syzop:
  [12:30:04] well the main site got hacked huh, so the md5sum on the website was reflecting the trojanized version
  [12:30:18] but nobody checked the md5sum against the one mentioned in the announcement
10. Re:It's nice that they're honest. by segmond · 2010-06-12 19:19 · Score: 1
  
  but it's also sad that they are not vigilant. the backdoor is a lame backdoor that a middle school kid could pull off. how no one noticed is unbelievable for so long!
  gemster@hidden:~/Unreal3.2$ grep DEBUG3_DOLOG_SYSTEM include/struct.h
  #define DEBUG3_LOG(x) DEBUG3_DOLOG_SYSTEM (x)
  #define DEBUG3_DOLOG_SYSTEM(x) system(x)
  gemster@hidden:~/Unreal3.2$
  freaking (system)
  it wasn't even something creative hidden with a race condition or buffer overflow, I hate to trust that ircd server, until the entire source is audited triple times over.
  
  --
  ------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
11. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 19:46 · Score: 0, Offtopic
  
  if you are referring to google collecting wifi data, google has no credible defense. grab a linux distro, mapping ssid is a matter of a 3 lines script. If they bothered to use more code, some evil is involved.
  He might also be referring to the belief some people seem to have that Google voluntarily disclosed this without any outside pressure. The fact is that they only disclosed this after European governments started demanding auditing the data the cars collected.
12. Re:It's nice that they're honest. by Runaway1956 · 2010-06-12 19:50 · Score: 4, Insightful
  
  Embarassing, in that, "Yes we screwed up, and we shouldn't have." or embarassing as in, "Oh shit, open source really isn't any better than security through obfuscation!"?
  If you mean the first, I'm with you. We all screw up - and sometimes we need a reminder that we can't duck, or blame on someone else to keep us on our toes.
  If you mean the second, well, I call bullshit. Several people have already pointed out that closed source shops are frequently the victims of malware. You can find a half dozen gadgets or softwares that have been SHIPPED FROM THE FACTORY with malware of some kind, just in the last year.
  Personally, I really prefer the situation at Unreal. It's open source. Everyone who gives a small damn had the opportunity to check it out. Anyone could have run any number of monitoring tools on the software, and caught it doing it's thing. When it was found, the administrators made an announcement. I like honesty and open communications.
  It's a helluva lot better than, for example, a closed source shop pushing an update to your telephone which opens your communications up to government monitoring. The only way THAT was discovered, was the relatively dramatic decrease in battery life immediately after the update was pushed.
  To each his own though. Those who put their faith in corporate masters are welcome to buy only proprietary stuff. I'll go with open source whenever possible!!
  
  --
  "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
13. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 20:15 · Score: 0
  
  Well, unless you're Google, in which case you're raked over the coals and accused of being at the right hand of the devil himself...
  If that were true, wouldn't that make you Steve Ballmer, and thus a Billionaire?
  Doesn't sound so bad too me.
14. Re:It's nice that they're honest. by jibjibjib · 2010-06-12 20:46 · Score: 3, Insightful
  
  Maybe (in fact, almost certainly) Google wanted to capture every packet, measure its signal strength and collect statistics to get more detailed maps of wireless networks than what a simple "3 lines" script would provide. Why would you discount that as not being "credible", but instead accept the even more incredible possibility that (despite until now being a legitimate business) they're involved in some sort of international conspiracy to illegally use random people's private wi-fi data?
  A common way of mapping wireless networks is using software like Kismet, which is in fact what Google used, and which in its default configuration saves all packets received. If you claim it must be true that "some evil is involved" because they used standard widely used software rather than your 3-line script, you don't know what you're talking about.
15. Re:It's nice that they're honest. by jibjibjib · 2010-06-12 20:49 · Score: 1
  
  it was not a screwup it was an intentional attack
  When we say a "screwup" we mean that the developers screwed up by making the project vulnerable to such an attack and not detecting it sooner.
16. Re:It's nice that they're honest. by Narcocide · 2010-06-12 21:33 · Score: 2, Funny
  
  Seriously, that's what you call unchecked paranoia. Nobody is ordering Microsoft grunts to sabotage open source software. They do that in their free time for fun.
17. Re:It's nice that they're honest. by indeterminator · 2010-06-12 22:03 · Score: 2, Interesting
  
  It's still an embarrassment for open source though.
  Talk about generalisation. One project getting rooted isn't representative to the rest of them in any way. Also, FTFA:
  
  CVS is also not affected.
  This was a case of distribution packages on their mirror site being replaced with malicious version, not a breakage of the development process. It's also something that happens all the time with closed source SW too, which is why you don't want to download installers from suspicious sites.
18. Re:It's nice that they're honest. by TheRaven64 · 2010-06-12 22:09 · Score: 0, Offtopic
  
  You're in the wrong article. The one about autism is a few further down the front page. In this one, you're supposed to have a sense of humour or, if you're American, a sense of humor.
  
  --
  I am TheRaven on Soylent News
19. Re:It's nice that they're honest. by grumbel · 2010-06-12 22:22 · Score: 1
  
  The problem is for "everyone can see the source" to work you need to have a guarantee that they are all looking at the same code. In this case I guess all the developers where looking at their CVS trees, while average Joe was just downloading and compiling the backdoored tarball. To stop this kind of problem from happening you would need to secure the source code via GPG signatures and make sure that users actually check those signatures. The first thing is what they are now doing and what many other projects do, the second part would however require that we stop using tar or at least wrapper it up to make the signature check an automatic thing of the extraction process. As long as the GPG check is thing that you need to take care of manually, most people will just never do it.
20. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 23:18 · 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.
21. Re:It's nice that they're honest. by keeboo · 2010-06-12 23:42 · Score: 4, Insightful
  
  3) was not included in the Debain repos, despite there being a willing maintainer, because of poor code quality- see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130
  The lack or presence of a software in Debian does not mean anything about its quality.
  Unfortunately there are are people, among the Debian devel, who are more political assholes than proper developers.
  
  An example of utter garbage present in Debian is pdns (the software itself collapses after running for few hours, even minutes, depending on your load). Yet, each new Debian release contains a new version of that software. -- And that's not the only case.
22. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-12 23:47 · Score: 0
  
  and as long as the GPG check is a thing that happens automatically, it too can be easily compromised.
  However, having the main site run automated checks to esure that the archives it serves are properly signed /would/ make sense.
23. Re:It's nice that they're honest. by DaveV1.0 · 2010-06-13 00:28 · Score: 0, Offtopic
  
  Unless, of course, one were hoping to use SSID + Signal strength to try to determine the user's position without accessing the WiFi network. You know, like what happens with Android phones.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
24. Re:It's nice that they're honest. by DaveV1.0 · 2010-06-13 00:33 · Score: 0, Redundant
  
  How about embarrassing as in "We have been claiming shit like this can't happen to us because we are open and everyone can look at the code and any change will be found and fixed quickly and this compromised code has been sitting out there for 8 months and no one noticed!"
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
25. Re:It's nice that they're honest. by DaveV1.0 · 2010-06-13 00:48 · Score: 1
  
  1) no one uses (not a single user checked the hash of the download over seven months)
  Logic fail, does not follow. Just because the hash has not been checked (which it might have been as the attacker could have replaced the hash on the server as well as the code), it does not follow that no one uses or no one has downloaded the code. The "many eyes" claim results in a false sense of security.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
26. Re:It's nice that they're honest. by Kjella · 2010-06-13 01:46 · Score: 2, Interesting
  
  Embarassing (sic), in that, "Yes we screwed up, and we shouldn't have." or embarassing (sic) as in, "Oh shit, open source really isn't any better than security through obfuscation!"?
  Well the old "many eyes" argument is getting embarrassing when it's obvious that all the eyes are on the front door while the window is wide open. As usual, it was not the VCS that was compromised, because many people at least casually look at commits, often it has to pass through a mailing list and often getting commit access is hard. Becoming a rouge committer is high risk/low yield, same with hacking a committer's computer. Hacking the VCS server would probably lead to the code changes showing up in diffs so that's not very subtle either.
  But then there's the downstream and binary builds. A few packagers, mirror maintainers and distro maintainers might look at these but hardly anybody else. A good example is the Debian OpenSSL fiasco a few years back. There's this one, that got caught. How many of these go unnoticed? How many really checks that nothing bad happened between the upstream VCS and the binary running on my server? How many makes sure the source and binary posted really match and compile to the same MD5 and won't just disregard it as different compiler versions and flags? Extremely few. Like in this case, it was no good checking the MD5 because it was also compromised...
  
  --
  Live today, because you never know what tomorrow brings
27. Re:It's nice that they're honest. by drinkypoo · 2010-06-13 02:28 · Score: 2, Funny
  
  You're in the wrong article. The one about autism is a few further down the front page. In this one, you're supposed to have a sense of humour or, if you're American, a sense of humor.
  That's it, I'm headed to the autism article to make a joke. Wapner, here I come!
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
28. Re:It's nice that they're honest. by LO0G · 2010-06-13 02:30 · Score: 1
  
  You have examples of a closed source product being shipped with a trojan binary in the official release vehicle?
  Not an example of a consumer electronics device that has malware shipped on the device (which isn't a OSS vs COSS issue) but an example of a COSS vendor shipping a trojaned binary on the official release site?
29. Re:It's nice that they're honest. by GooberToo · 2010-06-13 02:33 · Score: 1
  
  Embarassing, in that, "Yes we screwed up, and we shouldn't have." or embarassing as in, "Oh shit, open source really isn't any better than security through obfuscation!"?
  Actually, it doesn't even mean that. Not in the least. This is about poor developers and a woefully obviously broken development process and broken developers.
  For this to be allowed to happen means no one is monitoring what is committed to the repository, let alone what is merged into production releases. This basically means those in charge of the development process are idiots. Did I mention they are absolute fucking idiots? This is the expected result be it open source or commercial software. Period. The morale doesn't have anything to do with obscurity. The morale is, don't release anything and everything simply because it was committed. Find me any developer who subscribes to the merge/release everything, without any sort of review, and I'll show you an unfit developer - without fail.
  In open source projects, like say the Linux Kernel, this stuff doesn't happen because people care what is being committed, merged, and released. This is FAR more a condemnation of the project and the developers in charge than it have anything to with open source. In short, if you ever needed an excuse to never use their code, now you have it. Unless lots of heads role, rest assured this type of stupidity is very likely to happen again with this project.
30. Re:It's nice that they're honest. by SIR_Taco · 2010-06-13 02:37 · Score: 1
  
  Sooo.... the devil is left handed then, since the right can do no evil?
  Good to know :)
  
  --
  I say don't drink and drive, you might spill your drink. Before you get behind the wheel just stop and think.
31. Re:It's nice that they're honest. by Zigurd · 2010-06-13 03:02 · Score: 4, 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.
  
  --
  I wrote parts of this stuff
32. Re:It's nice that they're honest. by icebraining · 2010-06-13 03:08 · Score: 1
  
  More code? Grabbing all the traffic is one:
  
  kismet
  
  Ok, two:
  
  aptitude install kismet kismet
  
  --
  Dilbert RSS feed
33. Re:It's nice that they're honest. by icebraining · 2010-06-13 03:10 · Score: 1
  
  Why isn't average Joe installing the IRC server from his distro, after being checked by the maintainer and signed to prevent tampering?
  
  --
  Dilbert RSS feed
34. Re:It's nice that they're honest. by icebraining · 2010-06-13 03:19 · Score: 1
  
  Although it only serves two PCs, my pdns installation has about one month of uptime right now and has never "collapsed".
  Also, I don't see your bug report, have you filed one? Or are you expecting the maintainers to magically find about it and fix it?
  I'm not saying it's perfect (it never is), but from what I can tell is very rare to find out such problems.
  
  --
  Dilbert RSS feed
35. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 03:30 · Score: 0
  
  Nobody fucking said that closed source was better. Quit making assumptions. Just because you criticize OSS doesn't make you a proponent of closed source.
36. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 03:58 · Score: 0
  
  > It's a helluva lot better than, for example, a closed source shop pushing an update to your telephone which opens your communications up to government monitoring. The only way THAT was discovered, was the relatively dramatic decrease in battery life immediately after the update was pushed.
  Wait, what? I somehow managed not to hear about this. :( Link for more info please?
37. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 04:00 · Score: 0
  
  Why isn't average Joe installing the IRC server from his distro, after being checked by the maintainer and signed to prevent tampering?
  FWIW, Gentoos ebuilds have had the backdoored versions too...
  http://bugs.gentoo.org/show_bug.cgi?id=323691
38. Re:It's nice that they're honest. by girlintraining · 2010-06-13 04:27 · Score: 1
  
  Either you hiccup'd or slashdot did. Wrong thread, dude.
  
  --
  #fuckbeta #iamslashdot #dicemustdie
39. Re:It's nice that they're honest. by Nyder · 2010-06-13 04:34 · Score: 1
  
  Well, unless you're Google, in which case you're raked over the coals and accused of being at the right hand of the devil himself...
  Unless your MS and you'll do whatever it takes to own the market...
  
  --
  Be seeing you...
40. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 05:18 · Score: 0
  
  I'm the owner of EFnet, I plan to sue the creators of Unreal for massive damages.
41. Re:It's nice that they're honest. by GofG · 2010-06-13 05:30 · Score: 2, Informative
  
  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.
  
  --
  GFA/M/S d-- s: a--- C++++ UBL++$ P+ L+++ !E- W++ N+ !o K- w--- !O !M !V PS++ PE Y+ PGP+ t+++ 5- X+ R tv@ b++ DI++++ D+ G
42. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 05:50 · Score: 1
  
  Either you hiccup'd or slashdot did. Wrong thread, dude.
  Click the 'Parent' button to move back up the thread and see what he's replying to. Or browse at a lower threshold.
43. Re:It's nice that they're honest. by sqlrob · 2010-06-13 05:52 · Score: 1
  
  Wargasm comes to mind (on install media). IIRC, that was around the same time as the Myth II installer debacle.
  Korean MSDN was shipping malware too
44. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 06:09 · Score: 0
  
  Please RTFA before flying off the handle. The code itself wasn't actually compromised. It was a substitution of infected distribution package on a mirror.
  I realize the article's title and twitter-esque length make it sound like something else, but this doesn't really excuse you from reading the links first.
  P.S. heads roll not role
45. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 06:19 · Score: 0
  
  Closed source generally has better QA than open source.
46. Re:It's nice that they're honest. by Psychochild · 2010-06-13 06:20 · Score: 1
  
  Yeah, because I get my proprietary applications from tarballs hosted on mirror servers.
  Er, wait....
  No, this wasn't an attack based on access to the source, but it was an attack that took advantage of the nature of open source software community. The lesson here is that open source advocates need to get off their high horses and accept that vulnerabilities happen, even to open source projects.
  
  --
  Brian "Psychochild" Green
  MMO developer's blog
47. Re:It's nice that they're honest. by Shark · 2010-06-13 06:47 · Score: 1
  
  You make very valid points. But to me that means a wakeup call for open source distribution, not open source software per say. You can reasonably trust open source code to be free of this sort of stuff. If you want to make sure it doesn't get compromised on its way to you, you need a distro that does its job of making sure the software it distributes hasn't been compromised along the way. The many eyes argument holds as far as the source is concerned. I don't think a 'many eyes' argument can be made as far as distribution goes.
  What this points out is a need for such a mechanism to extend further down the path from software writers to software users. If that need becomes important enough, some entity will take care of it.
  
  --
  Mind the frickin' laser...
48. Re:It's nice that they're honest. by cbiltcliffe · 2010-06-13 07:42 · Score: 1
  
  Unless your MS and you'll do whatever it takes to own the market...
  You mean:
  Unless your MS and youll do whatever it takes. :)
  Or maybe:
  Unless my MS what?
  I'm not usually such a grammar nazi, but it's kind of unusual to see one incorrect usage, and one correct usage within 4 words of each other.
  
  --
  "City hall" in German is "Rathaus" Kinda explains a few things......
49. Re:It's nice that they're honest. by HiThere · 2010-06-13 08:03 · Score: 1
  
  I've heard that assertion before, but I've never seen any evidence to back it up. (Well, not strictly true. Back around 1998 I think I did see some evidence, but I couldn't check it's honesty.)
  If I were to assert that all proprietary software were an incredible garbage pit of sloppy hacks and unchecked array references you couldn't prove me wrong. But there's good evidence that that describes much proprietary software. (And I left out copyright infringement.)
  Now I think my proposed assertion is wrong, but not as wrong as your assertion . OTOH, neither of us can prove it using any commonly accepted standard of proof.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
50. Re:It's nice that they're honest. by HiThere · 2010-06-13 08:16 · Score: 1
  
  FWIW, I've run into problems trying to file bug reports. It's generally been harder to file the reports than to deal with the problem.
  Now in this particular case the complaining party apparently could identify the bug down to "which package is causing the problem", but I usually can't. My system will have been working fine, until suddenly it isn't. Then the system asks me to file a bug report on some package, and I've no idea why the system suddenly failed. I wasn't, as far as I knew, doing anything unusual. I suspect some background process, but probably one I don't even know the name of. And the first question I'm supposed to answer is "What package caused the problem?"
  Onwards to another class of problems. This one I can clearly identify the culprit: The interaction between FireFox and Slashdot. Occasionally the new Slashdot code will get locked into a loop that totally locks up my system. The mouse pointer will still move, but there's no response to clicks, and the keyboard won't even respond to the caps lock key. (I.e., the status light won't change.) I've occasionally waited for half an hour, and the problem doesn't time out or resolve. The only answer I've found is to force a reboot. I can't even switch to another terminal and kill the process. When I reboot there are two orphaned blocks on the /home partition, but everything is back to normal.
  But if there's any place to report this, I sure can't find it.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
51. Re:It's nice that they're honest. by HiThere · 2010-06-13 08:47 · Score: 2, Insightful
  
  Who's been claiming that things like this couldn't happen?
  This is the reason that both deb's and rpm's went to signing all packages, and the reason that best practice requires that signatures not be hosted on the same server as the binaries. (OTOH, I've got to admit that these "best practices" aren't always followed. And I'm currently trusting a package from one site that doesn't sign it's debs with a signature I'm willing to trust. But if I were conscientious I wouldn't use that package.)
  So, yeah, this is the kind of thing that "best practices" are intended to prevent, and we don't always follow the best practices, because they are less convenient. But if we care, we can tell whether best practices are being followed.
  Now tarballs are a different kind of beast. Perhaps Slackware has some way to deal with the problem of tarball authentication that I don't know of. But lacking that I always feel that using a tarball is taking a risk. And that one should have one's eyes open to that problem. With a tarball you don't know who you're trusting. If you use hashcode verification stored on the same server as the tarball, then the hashcode doesn't prove anything. (For that reason Python always posts both the MD5 and the pgp key on their website [A separate server from their download server]. This is, at least close to, best practices for tarballs.)
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
52. Re:It's nice that they're honest. by HiThere · 2010-06-13 08:56 · Score: 2, Insightful
  
  The GPG check can also fail if they just get you to add their private key into you list of trusted keys. This is a point that has occasionally bothered me. There doesn't seem to be any decent way to authenticate that the key you're being asked to add is one that should be trusted. Web of trust was a decent approach, but it didn't scale. It demanded personal meetings and the new person being vouched for by the old one. When it got expanded onto the web, the process got broken.
  Someone needs to start thinking seriously about this. Someone with decent knowledge of security, and a knowledge of FOSS procedures. And someone friendly to FOSS. And with decent political connections within the community.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
53. Re:It's nice that they're honest. by GofG · 2010-06-13 09:15 · Score: 2, Insightful
  
  None of the software I use comes from tarballs either; I get it all from trusted repositories. That particular method is only one step down on the security level from inspecting all of the source of all of the applications you use personally. All of the software I use is open source and very secure; what do I have to worry about? It doesn't have anything to do with the open-source status of the software, it has to do with the distribution method. There are safe and unsafe distribution methods; downloading software from a sketchy mirror is dangerous regardless of the openness or closedness of the source. Downloading from a trusted website (such as ftp.archlinux.fr or cnet.com) is relatively safe, whether you're doing so through your package manage or your browser, whether the software is open or closed source. This incident can do nothing to hurt the reputation of the security of open-source software in the debate vs closed-source software as they both suffer from this security flaw.
  
  --
  GFA/M/S d-- s: a--- C++++ UBL++$ P+ L+++ !E- W++ N+ !o K- w--- !O !M !V PS++ PE Y+ PGP+ t+++ 5- X+ R tv@ b++ DI++++ D+ G
54. Re:It's nice that they're honest. by grumbel · 2010-06-13 09:58 · Score: 1
  
  Someone needs to start thinking seriously about this.
  The best approach so far is the SSH one, give a short warning when connecting to a new host, but let the user connect, but give a big fat warning when the host key changes later on.
  The important part when it comes to signing of downloads isn't that you can guarantee that it comes from a trusted good source, but simply that it comes from the same source as the last few downloads.
55. Re:It's nice that they're honest. by kiwimate · 2010-06-13 12:07 · Score: 1
  
  Personally, I really prefer the situation at Unreal. It's open source. Everyone who gives a small damn had the opportunity to check it out. Anyone could have run any number of monitoring tools on the software, and caught it doing it's thing.
  But nobody did; that's the problem. It's all nice that you can check it; but if you are in a situation where most people prefer to choose to believe/hope/pray that someone else will, well, then, the advantage of being able to view the source isn't really an advantage if no-one utilizes said advantage.
  And if you really want to encourage the ordinary non-technical user to adopt Linux, then you have to be aware of that. Even plenty of highly technical users will not check the code, for the simple reason it's not their skill; there are a lot of highly technical users who aren't programmers, or are programmers but aren't kernel programmers. Or they don't have the time. Or the motivation. Plenty of reasons why some who has the ability to check code simply will not do so.
  Etc. Oh, what the hell...I could rattle on and it'll do no good, because I'll get shouted down by people getting desperately defensive rather than responding with "yeah, problem, how do we as a community fix it and give non-technical users the confidence".
  Because that really is a problem. Try explaining to a non-technical user how open source works and the first thing they'll think of is "so anyone can stick their own code in? Huh...doesn't seem very secure". Trying to say "but anyone can check it!" will only make them respond "I can't, can you? And if you can, do you take the time to do so? All of it? No? Well, who does? How do you know they do?..." etc.
  Good luck...you'll need it if you ever are to get to the year of Linux on the desktop.
56. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 13:03 · Score: 1, Funny
  
  Wow. Why the fuck would you use such a shit operating system that can fail so massively? That kind of shit never happens on OS X or Windows.
  You must be some kind of computing masochist.
57. Re:It's nice that they're honest. by oztiks · 2010-06-13 13:10 · Score: 1
  
  And if your Linux you're always the victim of unsuspecting FUD clouding everyone's judgment.
  http://www.zdnet.com/blog/bott/linux-infection-proves-windows-malware-monopoly-is-over/2206?tag=mantle_skin;content
  This article is hardly what I'd consider a fair call.
58. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 18:51 · Score: 0
  
  Like in this case, it was no good checking the MD5 because it was also compromised...
  Uh, what kind of idiot uses the checksums on a mirror rather than the main site?
59. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 19:26 · Score: 0
  
  "Carsten Munk has specifically requested that UnrealIRCd not be included
  in Debian, and will likely be hostile towards it's inclusion."
  Debian has about 1000 volunteers.. In that many people there will be some "political assholes". Of course, there are political assholes (in my personal opinion) outside of Debian too. Some of them include cdrecord dev (Jörg Schilling). Jörg Schilling repeatedly threatened Debian developers with "legal action" over using cdrecord in accordance to the license, and not his wishes. It's all public on lists.debian.org.
  Since Debian tries to avoid these kind of scenarios in the future, ftp masters probably would deny any package of UnrealIRCd anyway because of Carsten Munk request - we don't want hostile upstreams.
  In this case this proved to be a blessing in disguise ;)
  Cheers!
  And speaking only for myself.
60. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 19:42 · Score: 0
  
  I agree... MicroSoft has never ever rereased a version a Windows without any security issues, they've never had to to "emergency update patch" any of their software, nor has there EVER been any stability issues with anything from theirs.
  OpenSource, on the other hand, is constantly rolling out updates
  *rolls eyes*
  Get a grip on reality, the_womble. MicroSoft and Adobe are the worst offenders of security issues there is.
61. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-13 19:53 · Score: 0
  
  Sounds like a hardware problem. (I know, the easiest answer for a software dev!)
  But seriously, check your ram, even if you need to waste a long weekend running memtest. A web browser locking up your desktop? You can't switch VTs or ssh in to kill it? You might check your CPU and mobo too...
62. Re:It's nice that they're honest. by hesaigo999ca · 2010-06-14 00:31 · Score: 1
  
  I agree with your point 100%, although I got modded down as troll for suggesting this very same thing on another post...wonder why some people can suggest it and get a pat on the back, and others get burned, guess that's the joy of /.
63. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-14 06:32 · Score: 0
  
  The devil IS a pretty sinister guy...
64. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-14 08:31 · Score: 0
  
  I can't be bothered logging in and not sure I remember my password, but you seemed so nice I just had to say hi. :D
  Now, you're saying that lazy admins who were running open source and as such thought they were invulnerable shold be applauded because they told people? MSFT tells people about a critical flaw discovered a few hours ago by a security researcher who's spent his whole life working on breaking Windows, and the comments would be along the lines of "Another MSFT fk up, FOSS FTW!".
  Not exact words, but you get the point. :P
  The admins were lazy. They were complacent. They should be all rights be shot. I'd add in torture as well but I'm saving that for something that actually affects people physically, not just a backdoor in an IRC server. But shot is still good. This should have been picked up within hours, days at the most. Not 4+ months. No hitting closed source here, because an admin on a MSFT server would have picked this up much quicker and had a patch out with a priority notice to all users at a speed which from your precious FOSS admins would call speedhax on.
  *barricades door and prepares for inevitable article saying a Windows admin recently found a vuln from 4 years back*
65. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-14 08:45 · Score: 0
  
  Many eyeballs doesn't work in this case, the admins need to have seen it. As a post below you stated, the md5 was also changed to make the exploited download seem legitimate. So regardless that you had quite a few people downloading this package and looking at it, it wouldn't, and indeed almost couldn't have been caught. The issue isn't that FOSS got hacked, because every sane and realistic (or cynical, you pick) person will know that you're going to get hacked eventually. It's why you check the hash of your downloads, run a firewall, have passwords other than "admin" and bet Germany's way versus Aus irregardless of nationality. But in this case, the admins were so sure they'd be fine that they uploaded it and left it there. The only way they could have found this, and I'd be very interested to find out if anyone knows, is if a bored admin checked the logs and saw an change that looked suspicious, a user was paranoid enough to be running a full on NIDS at the time the backdoor was accessed, or someone went through the code. Which would have to be a new user because no-ones going to check the source of an app 4 months after they've downloaded and installed it.
  On Windows, an exe is hit without enough malware scans and paranoid eyes that getting this long is practically impossible. On a *nix (and Apple really), you all think you're invulnerable because it's FOSS.
  Don't take this as an insult, but read the bug report, read all the documentation you can find on this, and start considering the thought that just maybe *nix isn't invulnerable after all.
  And spare a moment for us poor bastards who have to deal with people trying this on us on a Windows server almost by the freaking second. -.-
  Heh. In other words, welcome to hell. No rosy eyes here, just cynics.
  It doesn't refute any of the arguments against FOSS, it's just a reminder to not become complacent.
66. Re:It's nice that they're honest. by Anonymous Coward · 2010-06-14 09:30 · Score: 0
  
  I also like the SSH approach of "You sure? We've never seen this server before" to "Wait, NO! This server is not the server you think!".
  But as someone who is interested in this, but has no valuable experience or education to think of a new method, I can't see how this could be moved into software package distribution. I'm specifically thinking of Ubuntu packages that are built and distributed by people (say over Launchpad.net) that don't have commit access to the actual source repository. They're community volunteers. Whats to stop them from inserting malicious code, compiling and packaging it up and seeding it to anyone that `aptitude install`s it?
  The server and signing key that I've already accepted from this person is verified as being legitimate, but I have no way of contacting anyone to make sure that the person building these packages and signing it with the key is trustworthy, other than accepting a rather broad understanding that if they take the time to contribute to the community, they must be doing good.
67. Re:It's nice that they're honest. by grumbel · 2010-06-14 10:03 · Score: 1
  
  Whats to stop them from inserting malicious code, compiling and packaging it up and seeding it to anyone that `aptitude install`s it?
  In a perfect world the key would need to have some minimum level of trust assigned to it to let it pass through automatic verification. And trust would be gained by both time and other people. Somebody who has registered a month ago on launchpad and was active over all that time is more trustworthy then somebody who created his account yesterday. Also people in the open source world could give trust to each other (i.e. when you want to upload something to Debian, you do it first via a mentor, not by yourself).
  Of course none of that would stop somebody from doing constructive work for a while and then running amok and uploading a backdoored version, but it would lower the likely hood a good bit and would make the clean up much easier, as everything the person uploaded could automatically be tracked and blacklisted.
  If all of that fails, which it might be due to the complications with manual trust assignment (hardly anybody understands it so nobody uses it, those that understand it require impractical high levels before they assign trust, i.e. person meeting) and alternative approach might be the way of a CA or what ebay is doing for verification. Each developer would give his real world address to Ubuntu, Sourceforge or another company and they would send a postcard with a code for verification. The developer would input that code and thus verify his real world address and thus gain trust from that company for his key. He could then go upload stuff with his key and would automatically be trusted on installation. It again wouldn't stop backdoor writers, but one might hesitate a good bit to upload a backdoored version when you have your real world address attached to it (not publically visible), as that kind of behaviour is a crime in quite a few countries.
68. Re:It's nice that they're honest. by HiThere · 2010-06-14 12:51 · Score: 1
  
  It's not just a browser, it's a browser + Slashdot. Never any other site.
  And never when I'm not on the web, compiling, editing, etc. So I don't think it's RAM. I suppose there might be some communications thing that Slashdot exercises, and other things don't, but RAM doesn't sound reasonable.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
Remember, kids! by Voulnet · 2010-06-12 17:35 · Score: 0

Always check the hash signatures of any application you use, or at least any application you wish to give internet access to!
1. Re:Remember, kids! by GigaplexNZ · 2010-06-12 17:41 · Score: 1
  
  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.
2. Re:Remember, kids! by Anonymous Coward · 2010-06-12 17:42 · Score: 0
  
  If they had access to the "Source Archive", why wouldn't they just change the signatures to something that matches?
3. Re:Remember, kids! by Stupendoussteve · 2010-06-12 17:44 · 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.
4. Re:Remember, kids! by FrangoAssado · 2010-06-12 17:56 · Score: 1
  
  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.
5. Re:Remember, kids! by Peach+Rings · 2010-06-12 18:39 · Score: 1
  
  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 !
6. Re:Remember, kids! by asdf7890 · 2010-06-12 18:47 · Score: 1
  
  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).
7. Re:Remember, kids! by mysidia · 2010-06-12 18:48 · Score: 1
  
  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:
  
  "The unreal site was listing the backdoored md5 as official."
  In addition, there were gentoo ebuilds using the trojanned source's signatures, and trojanned sources on Gentoo mirrors
8. Re:Remember, kids! by GigaplexNZ · 2010-06-12 19:38 · Score: 1
  
  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
9. Re:Remember, kids! by Anonymous Coward · 2010-06-12 19:57 · Score: 0
  
  I just about always check the hashcodes just to make sure the download was successful. I'm less careful about checking GPG signatures than I should be...
10. Re:Remember, kids! by Anonymous Coward · 2010-06-12 20:09 · Score: 0
  
  As a Gentoo user, I hope this leads to an audit of all packages. At the time of this post I verified that gentoo ebuild package system had a manifest containing checksums of the bad archive and has so at least since December 21st 2009.
  The great part of this is that 3.2.8.1 was quickly stabilized (except on amd64) because of a dos in 3.2.7. WTG guys.
11. Re:Remember, kids! by Anonymous Coward · 2010-06-12 21:40 · Score: 0
  
  I always check them too, mainly to check for corrupted downloads.
12. Re:Remember, kids! by Stupendoussteve · 2010-06-13 00:48 · Score: 1
  
  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.
13. Re:Remember, kids! by Hatta · 2010-06-13 02:39 · Score: 2, 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.
  
  --
  Give me Classic Slashdot or give me death!
14. Re:Remember, kids! by kerrbear · 2010-06-13 02:44 · Score: 1
  
  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.
15. Re:Remember, kids! by logjon · 2010-06-13 03:06 · Score: 0
  
  If you're going to assume it's okay should the hashes not match, why bother checking in the first place?
  
  --
  The stories and info posted here are artistic works of fiction and falsehood.
  Only fools would take it as fact.
16. Re:Remember, kids! by Anonymous Coward · 2010-06-13 04:21 · Score: 0
  
  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.
  Unfortunately, it seems almost no one checks it.
17. Re:Remember, kids! by cbiltcliffe · 2010-06-13 08:57 · Score: 1
  
  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......
18. Re:Remember, kids! by Anonymous Coward · 2010-06-13 14:39 · Score: 0
  
  It also means that the server does not check modified files.
Open source by MrNaz · 2010-06-12 17:37 · Score: 0, Troll

The fact that this can get into the program is a weakness of the open source model. The fact that it can be found so quickly is a strength of the open source model.

--
I hate printers.
1. Re:Open source by Stupendoussteve · 2010-06-12 17:46 · Score: 3, Insightful
  
  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).
2. Re:Open source by tsj5j · 2010-06-12 17:52 · Score: 5, Informative
  
  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.
3. Re:Open source by MrNaz · 2010-06-12 18:14 · Score: 2, Insightful
  
  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.
4. Re:Open source by bhtooefr · 2010-06-12 22:15 · Score: 1
  
  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.
5. Re:Open source by Anonymous Coward · 2010-06-12 22:48 · Score: 0
  
  Many eyes (too busy staring at porn to notice the malicious code)
Windows safer than linux by nicknamesarefunny · 2010-06-12 17:37 · Score: 1, Funny

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!
1. Re:Windows safer than linux by Rijnzael · 2010-06-12 18:01 · Score: 2, Insightful
  
  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.
2. Re:Windows safer than linux by mysidia · 2010-06-12 18:51 · Score: 1
  
  The windows provided BINARIES were not effected. If you compiled the windows version from source code, it was also effected.
3. Re:Windows safer than linux by Anonymous Coward · 2010-06-12 19:28 · Score: 1, Informative
  
  No, the Windows binaries were not affected. If you compiled them, they would have been affected.
Only some versions affected by jaak · 2010-06-12 17:43 · 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.
The remediation advice is wrong by poppycock · 2010-06-12 17:44 · Score: 2, Insightful

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.
1. Re:The remediation advice is wrong by Stupendoussteve · 2010-06-12 17:48 · Score: 2, Insightful
  
  If you're running an ircd as root you deserve whatever you get.
2. Re:The remediation advice is wrong by PiAndWhippedCream · 2010-06-12 17:51 · Score: 1
  
  LiveCD.
3. Re:The remediation advice is wrong by poppycock · 2010-06-12 17:54 · Score: 4, Insightful
  
  Yes, of course. Because its not even conceivable that the intruder has any local exploits.
4. Re:The remediation advice is wrong by poppycock · 2010-06-12 17:58 · Score: 1
  
  Yeah, LiveCD is an option if you have it.
5. Re:The remediation advice is wrong by mysidia · 2010-06-12 18:53 · Score: 5, Funny
  
  May I remind you that the Windows binaries are unaffected?
6. Re:The remediation advice is wrong by Anonymous Coward · 2010-06-12 18:58 · Score: 0
  
  I think for most irc server admins it isn't the box they are worried about losing integrety on so much as the network it connects to.
7. Re:The remediation advice is wrong by cbhacking · 2010-06-12 20:29 · Score: 1
  
  If you installed your ircd without doing anything that requires root, you're using an unusual install approach (it's totally possible, of course, just unusual). There's no need for the exploit to occur when you run the program; put the exploit payload in the installer and you get far higher permissions for it to play with.
  
  --
  There's no place I could be, since I've found Serenity...
8. Re:The remediation advice is wrong by Anonymous Coward · 2010-06-12 20:53 · Score: 0
  
  You install unreal as a regular user. For that matter, in my case, i run all irc related apps (qwebirc, anope and unreal) on a seperate account, which nothing else runs on, though its mainly as a housekeeping procedure, and none of those need elevated rights to install or run.
9. Re:The remediation advice is wrong by jibjibjib · 2010-06-12 20:55 · Score: 1
  
  But since the exploit source is available, we can easily see that the exploit modified the IRCd code and not any installation code.
10. Re:The remediation advice is wrong by X0563511 · 2010-06-12 21:23 · Score: 1
  
  --prefix=/opt/ircd is such an unusual approach? (assuming your user can write there, put it wherever else, even under ~/)
  
  --
  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...
11. Re:The remediation advice is wrong by cbhacking · 2010-06-12 21:46 · Score: 1
  
  Linux users, on average, are more savvy than Windows or Mac users... but a lot of them still tend to install things using their package manager or, lacking that as an option, via ./configure && make && sudo make install (or possibly putting each on its own line). Even standard configure arguments, like --prefix, are relatively unknown to your average Ubuntu or user. Besides, to most of the computer-using world (and remember that most Linux users didn't grow up with it, they came from Windows or possibly Mac OS) software installation is something done as Admin/root, almost by definition.
  
  --
  There's no place I could be, since I've found Serenity...
12. Re:The remediation advice is wrong by Anonymous Coward · 2010-06-12 22:20 · Score: 0
  
  Linux users, on average, are more savvy than Windows or Mac users... but a lot of them still tend to install things using their package manager
  Are you really implying that using the package manager indicates a reduction in savviness?
13. Re:The remediation advice is wrong by DarkOx · 2010-06-12 23:31 · Score: 1
  
  Well the truly paranoid but still polite person will download the software from the mirror and the check hashes. (S)He would then also download the hashes from the projects main site. First the hashes would be checked to make sure they match and then then if they do you validate the package hashes to that same value.
  Bandwidth has gotten cheap enough these days that most projects can afford to transfer at least the checksums to end users.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
14. Re:The remediation advice is wrong by icebraining · 2010-06-13 03:33 · Score: 1
  
  Installing from the repositories (at least in APT) never runs the original installer. The package manager (dpkg) reads the debian control files for the list of files to be installed and copies them itself. It can also run the post-inst scripts, but those are written by the maintainer, not the upstream devs (therefore, not the infected code).
  
  --
  Dilbert RSS feed
15. Re:The remediation advice is wrong by Stray7Xi · 2010-06-13 06:47 · Score: 1
  
  Correct answer is to make a service account, should also not run it as your user account. Otherwise they can add something to your path in your .bashrc and put their md5sum there.
  Also a service like ircd is pretty simplistic on what capabilities it needs, so it should have an apparmor or selinux profile. That should prevent practically any possibility of local elevation.
16. Re:The remediation advice is wrong by Stray7Xi · 2010-06-13 06:53 · Score: 1
  
  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.
  That requires root access (unless your path is wonky or screwed with). One additional thing you can check is put a known good copy of a statically linked md5sum in your home directory and run that. That should protect you from all user-mode rootkits (even with root access). Kernel-mode rootkits are always a possibility to screw you though.
17. Re:The remediation advice is wrong by Anonymous Coward · 2010-06-13 16:47 · Score: 0
  
  "Look at me! I do everything the hard, complicated way because I'm smarter!"
Backdoor allows user to execute ANY command by qubezz · 2010-06-12 18:02 · Score: 2, Funny

/me wants root hackboy wants root /mode #localhost +root hackboy ***irc.efnet.xxx sets mode: +root hackboy @#hackboy: Spoon! /msg localhost yes | rm -rf / ***Connection reset by peer
1. Re:Backdoor allows user to execute ANY command by mysidia · 2010-06-12 19:03 · Score: 1
  
  Sure, but that would be almost benign, compared to other possibilities -- bad guys having newly acquired access to the IRC server, could move to link rogue servers in, intercept user traffic, and more effectively generate mass ads for malware-infested websites, while getting users' NickServ passwords all at the same time?
2. Re:Backdoor allows user to execute ANY command by caluml · 2010-06-13 00:49 · Score: 1
  
  It'd be nice if all IRC servers spoke a common protocol - then a network could use a variety of different IRCds.
  I migrated from Unreal to Inspircd about a year ago (phew), and it was a problem. I had (until then) assumed that the IRC linking protocol was a common protocol (like SMTP or XMPP). Oh no.
  So, to all the IRC software people - get together, and standardise on a single format. You can have an "extensions" section in the protocol for your specific additions, but make it a general, federated protocol.
  
  --
  Get your own free personal location tracker
3. Re:Backdoor allows user to execute ANY command by mysidia · 2010-06-13 03:36 · Score: 1
  
  The chance of that happening is basically nil, everyone wants their own custom extensions that require all servers to implement.
  IRC Networks are closely knit entities where multiple servers connect together and implement all the same features, rules, and policies, in order to form a common platform.
  It makes no sense for servers with incompatible feature sets to be able to link, too much a security risk for the network itself...
4. Re:Backdoor allows user to execute ANY command by drinkypoo · 2010-06-13 05:31 · Score: 1
  
  What does IRC offer that isn't in something newer, like XMPP?
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
5. Re:Backdoor allows user to execute ANY command by Anonymous Coward · 2010-06-13 06:14 · Score: 0
  
  What does IRC offer that isn't in something newer, like XMPP?
  Nostalgia
6. Re:Backdoor allows user to execute ANY command by Anonymous Coward · 2010-06-14 06:02 · Score: 0
  
  Wow you are a tool...efnet doesnt even use unrealircd...quit posting lame shit like your cool...
Kinda funny.... by Anonymous Coward · 2010-06-12 18:31 · Score: 0

AVG reports a front page link as the highest risk it reports :P
Well yes... by Anonymous Coward · 2010-06-12 18:50 · Score: 5, Insightful

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).
1. Re:Well yes... by kthreadd · 2010-06-12 20:15 · Score: 1
  
  hirdly, 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.
  I am looking at it the other way around. There is not really any reasons now to require root access in order to listen on ports below 1024.
  It made a lot of sense during the 70's and 80's, that you could basically trust individual computers and that some untrusted user would not set up a service that looked official and legitimate. But the time has changed and we have things like cryptographic software that take much of that away.
  Actually almost every service that listens on ports below 1024 could run without superuser privileges. The fact that we are basically forced to run them as such is much worse than the false sense of security that the 1024 port limit gives us.
2. Re:Well yes... by jibjibjib · 2010-06-12 20:57 · Score: 1
  
  You're not forced to run those services as root. You can have something open the port then drop root privileges. Or you can set up firewall rules or a proxy of some sort to forward everything from the lower-numbered port onto a higher port, and not need the server software to ever be root at all.
3. Re:Well yes... by X0563511 · 2010-06-12 21:26 · Score: 2, Insightful
  
  It's there for a reason.
  If a server is compromised, the "normal" ports cannot be set up as listeners without also escalating your breakin.
  
  --
  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...
4. Re:Well yes... by Anonymous Coward · 2010-06-13 00:36 · Score: 0
  
  Yusuf, is that you?
5. Re:Well yes... by caluml · 2010-06-13 00:53 · Score: 3, Insightful
  
  I am looking at it the other way around. There is not really any reasons now to require root access in order to listen on ports below 1024.
  Amen. I'm glad I'm not the only one. In this day and age, where anyone can run a Unix box, the whole "root under 1024" thing is redundant. http://calum.org/posts/root-to-bind-to-ports-under-1024.
  
  Make it a damn kernel config option at the very least, and let me decide.
  
  --
  Get your own free personal location tracker
6. Re:Well yes... by bstreiff · 2010-06-13 00:56 · Score: 2, Informative
  
  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.
7. Re:Well yes... by Anonymous Coward · 2010-06-13 03:21 · Score: 0
  
  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.
  I call bullshit on this. There's plenty of daemons that manage to run on priviledged ports just fine without getting rooted regularly, and there's no reason why an IRC server should be any different.
  I mean, just bind to the port as early as possible, then drop priviledges. Sure, running on a high port and never running as root at all is still not a bad idea, but I don't buy into the notion that it's somehow necessary in order to be secure.
8. Re:Well yes... by Anonymous Coward · 2010-06-13 06:23 · Score: 0
  
  "just bind to the port as early as possible, then drop priviledges"
  This is unnecessary complexity, duplicated into every such program. We know that's a bad idea from a security design POV. LOTS of people have built software that gets this wrong, dropping privileges in the wrong order, or in a way that's reversible (the bad guys can call setuid too...)
  So, modern Linux kernels provide a mechanism to donate capabilities (binding low ports is a capability which by default happens to only be given to root) to binaries. In some pleasant future you (or the distro) will simply donate this capability to each server daemon.
9. Re:Well yes... by rjstanford · 2010-06-13 06:52 · Score: 1
  
  You're not forced to run those services as root. You can have something open the port then drop root privileges.
  From an exploit standpoint, once its running as root, even for "just a little bit", you're vulnerable.
  
  Or you can set up firewall rules or a proxy of some sort to forward everything from the lower-numbered port onto a higher port, and not need the server software to ever be root at all.
  This is a bit better, assuming you can trust your proxy :)
  
  --
  You're special forces then? That's great! I just love your olympics!
10. Re:Well yes... by Anonymous Coward · 2010-06-14 08:56 · Score: 0
  
  From a denzien of the net.
  IRC traffic really isn't that hard to pickup if you do a port scan, it's assumed that the official port won't be used.
  Security advice for Windows users, change your ports and passwords from default. Security advice to malware writers, don't assume the ports are static and include adm1n in your list of passwords.
  Anyone sane would have checked the logs daily to see if anything like this had happened on their server. Anyone sane would be running a NIDS to check for occurences like this. Anyone sane would have a malware removal scanner which they run daily to check for instances like this.
  From a Windows point of view, getting access to the machine is the hard part, escalating priveleges is the easy part. I haven't tried breaking *nix as often, it was boring. What's the point apart from the challenge, and challenges are cooler when you can go to an admin, "hey, check this" and take over. Assuming the admin is a friend who won't throw you in jail of course. :P But the backdoor, if it's written well, won't assume you're running default ports. And the first thing the hacker will do is install a rootkit on your machine then shutdown the backdoor. You find the backdoor, you won't find the rootkit, and vice versa.
  tl:dr
  Long post to say default ports won't really matter that much. A well written backdoor won't rely on them so neither should you.
Well by trifish · 2010-06-12 19:50 · Score: 1

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
1. Re:Well by X0563511 · 2010-06-12 21:27 · Score: 0
  
  Even so, often the more efficient way is to sign the hash.
  If nobody cares enough to verify the hash, what makes you think they will verify the signature?
  
  --
  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...
2. Re:Well by cbhacking · 2010-06-12 21:49 · Score: 1
  
  You can add a small layer of security (easily bypassed if the attacker knows where to look, but still...) by placing the hash and/or signature verification in your installer. Add something to the config scripts, or possibly to your makefile. If you offer pre-built packages, it's even easier.
  
  --
  There's no place I could be, since I've found Serenity...
3. Re:Well by naplam33 · 2010-06-12 23:14 · Score: 0
  
  Nobody checks the signatures. But yeah, somebody would eventually have noticed in 1.5 years and told the maintainers if they had signed the packages.
4. Re:Well by Anonymous Coward · 2010-06-12 23:21 · Score: 0
  
  It's not my problem. I check them. But most importantly, if only 1% of users checked them, then it wouldn't take more than ~100 downloads before someone noticed and alerted the authors.
  (Posted as A/C because I'm not interested in replies from someone as stupid as you.)
5. Re:Well by trifish · 2010-06-12 23:45 · Score: 2, Insightful
  
  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).
6. Re:Well by DaveV1.0 · 2010-06-13 00:16 · Score: 1
  
  Sounds to me like you are suggesting security through obscurity. Isn't that something that gets soundly derided here on slashdot when used in proprietary code? Why, yes, yes it is.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
7. Re:Well by cbhacking · 2010-06-13 02:10 · Score: 1
  
  What I'm suggesting is part of a defense in depth. You can't rely on security through obscurity, but obscurity can provide some assistance. The concept that security through obscurity is fundamentally flawed comes from encryption/hash algorithms, which are so complex that attempting to cook your own in secret is likely to result in something that is actually easier to crack - even though you either must first reverse-engineer how it works or just use brute force - than a published and thoroughly reviewed, tested, and revised algorithm.
  I say again, a small layer of security; it's not something you can rely on, alone, but it is something that will stop a careless attacker and will take some time from a knowledgeable one, for very little cost on your part.
  
  --
  There's no place I could be, since I've found Serenity...
8. Re:Well by XanC · 2010-06-13 04:25 · Score: 1
  
  Actually, if 1% at random check, then after 100 downloads, you've still got a 37% chance that nobody has checked. .99^100 = .36603
9. Re:Well by logjon · 2010-06-13 05:36 · Score: 0
  
  sed doesn't take a lot of time for a knowledgeable hacker
  
  --
  The stories and info posted here are artistic works of fiction and falsehood.
  Only fools would take it as fact.
10. Re:Well by X0563511 · 2010-06-13 07:01 · Score: 0
  
  It's faster to verify a blob of MD5-sums than your 200MB+ application. The blob can still verify the 200MB+ on it's own without bothering with the heavy-crypto. Save the expensive calculation for where it's really needed.
  
  --
  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...
11. Re:Well by trifish · 2010-06-13 07:16 · Score: 2, Insightful
  
  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.
12. Re:Well by X0563511 · 2010-06-13 21:49 · Score: 2, 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.
  
  --
  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...
13. Re:Well by Anonymous Coward · 2010-06-14 02:18 · Score: 0
  
  You're an idiot. Two posts and you still didn't get it. It's simple:
  The person who releases the stuff does this:
  1) Hashes the file.
  2) Signs the hash.
  3) Publishes the signature (WHICH IS A SIGNED HASH).
  The person who downloads.
  1) Hashes the file (HE *HAS* TO HASH THE FILE NO MATTER WHAT YOU THINK)
  2) Compares the hash with the published. If they match, proceed with 3)
  3) Verify the signature of the hash. If it is ok, you've verified the digital signature.
  If you still don't understand this, you're an idiot and beyond any help.
  I'm not going to watch this for answers. I'm not gonna waste my time with an idiot.
Comment removed by account_deleted · 2010-06-12 20:14 · Score: 4, Informative

Comment removed based on user account deletion
Whew! by Katchu · 2010-06-12 20:19 · Score: 1

That's what I like about open source. Eventually things get found out.

--
Keep Doing Good.
1. Re:Whew! by Anonymous Coward · 2010-06-12 20:45 · Score: 0
  
  Even if it takes 8 months with an MD5 that doesn't even match.
2. Re:Whew! by DaveV1.0 · 2010-06-12 23:28 · Score: 1
  
  Yes, because this could have happened to closed-source software and no one would have known and it would never have been found.
  Oh wait, we know that to be false.
  This happened specifically because UnrealIRC is open source. And, let us not forget that many flossies love to talk about how such things as this can't happen because so many people are looking at the source code.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
3. Re:Whew! by Datamonstar · 2010-06-13 00:03 · Score: 1
  
  No one with any real clout in the OSS industry has ever claimed that OSS is 100% free of evil code simply because it's open. What usually happens is exactly what happens here, the problem is discovered and disclosed to the community. Now how different that is from a closed-source offering I don't know because I've never worked with anything like that. But with open source the code is there and you're free to review it if you want to and know how.
  
  --
  The eternal struggle of good vs. evil begins within one's self.
4. Re:Whew! by DaveV1.0 · 2010-06-13 00:11 · Score: 1
  
  Yes, it only took a YEAR for it to be found.
  
  But with open source the code is there and you're free to review it if you want to and know how.
  You forgot that the person also has to have the time and resources, which most normal people don't have. The SAs and programmers where I work don't have the time to download and review the source of every bit of free software used in the company. And, I could do it for my personal systems, but I don't know C, C++, Python, and every other programming language used for the software and even if I did, I would not want to give up my free time to do that.
  The claim that FLOSS is more secure because of "many eyes" is just as bogus as security through obscurity.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
5. Re:Whew! by DaveV1.0 · 2010-06-13 00:14 · Score: 1
  
  Excuse me HALF A YEAR.
  
  --
  There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
6. Re:Whew! by Hatta · 2010-06-13 02:49 · Score: 0
  
  Yes, this could have happened to closed source software. It's harder to patch a binary to add malicious code, but not impossible.
  The real problem is that UnrealIRCd isn't open source enough. If they complied with DFSG guidelines, they'd be in Apt, and we'd have signed packages without them having to do anything. That would have stopped this attack dead.
  
  --
  Give me Classic Slashdot or give me death!
7. Re:Whew! by DaveV1.0 · 2010-06-13 03:10 · Score: 2
  
  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.
8. Re:Whew! by Anonymous Coward · 2010-06-13 06:23 · Score: 0
  
  Please RTFA. The CVS code was fine so the "many eyes" didn't have a chance to catch the problem. The mirror(s) were serving a compromised version.
9. Re:Whew! by Anonymous Coward · 2010-06-13 06:34 · Score: 0
  
  Of course, we all know there has never been a vulnerability that existed in closed source software for a whole 6 months. And every time a vulnerability is found in closed source software, it's always clearly publicized by the developers themselves so that everyone who could potentially could have been affected knows about it and takes care of it.
Re:Gentoo (Linux) not affected by miknix · 2010-06-12 22:42 · Score: 1, 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
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:Gentoo (Linux) not affected by Anonymous Coward · 2010-06-12 23:31 · 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.
many eyeballs Mirkwood forest by epine · 2010-06-13 01:23 · Score: 1

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.
With greater source code freedom... by Jugalator · 2010-06-13 02:55 · Score: 1

... 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!
Additional information by Anonymous Coward · 2010-06-13 03:28 · Score: 0

The advisory seems to misleading to some folks, so I'll make things more clear:
The backdoor was only present in the 3.2.8.1 tarball during November and yesterday. It affects *all* platforms, but not the installers, because the installers where made using a clean tarball before the intrusion. The attackers did not touch those.
Ho boy by Dega704 · 2010-06-13 03:51 · Score: 1

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.
1. Re:Ho boy by niftymitch · 2010-06-14 05:58 · Score: 1
  
  While malware of all types are rare on *inux and friends this incident does or should ring a wake up call that security is not free and is only the result of discipline and vigilance.
  And your point about "monoi-culture" is spot on.
  Desktop Linux will continue to make inroads unless patent, copyright, DRM and other coalitions make it impossible.
  A couple years back ssh was a problem and folk had to revert to rsh. We all need to keep healthy multiple versions so a fall back method is at hand. Alternates seems to be underused in the Linux community just as chroot is underused.
  alternatives can be used to eliminate too interesting tools or expose interesting tools. Same with SELinux. Consider a SELinux context for individuals that was simple but reserved for development, banking, email, www surfing, /., i.e. parallel but compartmentalized activities.
  I never toss a working laptop. They are like cars when you work on cars or laptops you need the second one to go and gets parts. In this case parts is software.
  
  --
  Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
The exploitation has begun by Anonymous Coward · 2010-06-13 04:11 · Score: 0

I urge EVERYONE that had a possibly exploitable version of UnrealIRCd running to check out the following comment:
http://www.irc-junkie.org/2010-06-12/some-unrealircd-3-2-8-1-downloads-trojaned/comment-page-1/#comment-3290
It seems the exploitation of the vulnerability has begun...
to client-hack by Anonymous Coward · 2010-06-13 08:56 · Score: 0

question is, what CLIENTS were owned?
i think only irssi was safe from the irc-demon ...