Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Communications Software

Backdoor Found In UnrealIRCd Source Archive 174

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Backdoor Found In UnrealIRCd Source Archive More

Backdoor Found In UnrealIRCd Source Archive

Comments Filter:

  • It's nice that they're honest. (Score:5, Insightful)

    by allaunjsilverfox2 ( 882195 ) on Sunday June 13, 2010 @12:34AM (#32554866) Homepage Journal
    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*

    • Re:It's nice that they're honest. (Score:4, Insightful)

      by Abcd1234 ( 188840 ) on Sunday June 13, 2010 @12:36AM (#32554872) Homepage

      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...

      • Re:It's nice that they're honest. (Score:5, Funny)

        by davester666 ( 731373 ) on Sunday June 13, 2010 @12:43AM (#32554926) Journal

        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.

      • Sooo.... the devil is left handed then, since the right can do no evil?

        Good to know :)

      • Re: (Score:2)

        by oztiks ( 921504 )

        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 [zdnet.com]

        This article is hardly what I'd consider a fair call.

    • Well, perhaps it was an inside job...

    • Re: (Score:3, Insightful)

      by Vahokif ( 1292866 )
      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.

      • Re:It's nice that they're honest. (Score:4, Insightful)

        by Runaway1956 ( 1322357 ) on Sunday June 13, 2010 @02:50AM (#32555334) Homepage Journal

        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!!

        • Comment removed (Score:5, Informative)

          by account_deleted ( 4530225 ) on Sunday June 13, 2010 @03:14AM (#32555382)
          Comment removed based on user account deletion

          • 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.

          • Re:It's nice that they're honest. (Score:5, Informative)

            by Zigurd ( 3528 ) on Sunday June 13, 2010 @10:02AM (#32556872) Homepage

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

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

        • Re: (Score:3, Interesting)

          by Kjella ( 173770 )

          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 diff

          • Re: (Score:2)

            by Shark ( 78448 )

            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

        • Re: (Score:2)

          by LO0G ( 606364 )

          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?

          • Re: (Score:2)

            by sqlrob ( 173498 )

            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

        • 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

        • 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 n

      • Re: (Score:2, Interesting)

        by indeterminator ( 1829904 )

        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.

      • Re: (Score:2)

        by grumbel ( 592662 )

        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 projec

        • Why isn't average Joe installing the IRC server from his distro, after being checked by the maintainer and signed to prevent tampering?

        • Re: (Score:3, Insightful)

          by HiThere ( 15173 )

          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 thin

          • Re: (Score:2)

            by grumbel ( 592662 )

            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.

    • Re: (Score:2)

      by segmond ( 34052 )

      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 a

  • 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!

    • Re: (Score:3, Insightful)

      by Rijnzael ( 1294596 )
      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.

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

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

      Of course it things could still go wrong if t

      • Re: (Score:2, Informative)

        by Anonymous Coward

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

  • 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.

  • 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.

    • Re: (Score:3, Insightful)

      by Stupendoussteve ( 891822 )

      If you're running an ircd as root you deserve whatever you get.

      • Re:The remediation advice is wrong (Score:4, Insightful)

        by poppycock ( 231161 ) on Sunday June 13, 2010 @12:54AM (#32554976)

        Yes, of course. Because its not even conceivable that the intruder has any local exploits.

        • Re:The remediation advice is wrong (Score:5, Funny)

          by mysidia ( 191772 ) on Sunday June 13, 2010 @01:53AM (#32555178)

          May I remind you that the Windows binaries are unaffected?

        • 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.

      • 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.

        • But since the exploit source is available, we can easily see that the exploit modified the IRCd code and not any installation code.

        • --prefix=/opt/ircd is such an unusual approach? (assuming your user can write there, put it wherever else, even under ~/)

          • 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 Window

            • 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).

    • LiveCD.

    • Re: (Score:2)

      by DarkOx ( 621550 )

      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.

    • 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.

  • Backdoor allows user to execute ANY command (Score:3, Funny)

    by qubezz ( 520511 ) on Sunday June 13, 2010 @01:02AM (#32555010)

    /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

  • Well yes... (Score:5, Insightful)

    by Anonymous Coward on Sunday June 13, 2010 @01:50AM (#32555172)

    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).

    • 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 withou

      • 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.

        • Re: (Score:2, Informative)

          by bstreiff ( 457409 )

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

        • 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 :)

      • Re: (Score:3, Insightful)

        by X0563511 ( 793323 )

        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.

      • Re:Well yes... (Score:4, Insightful)

        by caluml ( 551744 ) <slashdotNO@SPAMspamgoeshere.calum.org> on Sunday June 13, 2010 @07:53AM (#32556286) Homepage

        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 [calum.org].

        Make it a damn kernel config option at the very least, and let me decide.

  • 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

  • ... 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.

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close