Linux IRC server leaves backdoor open A warning today that Linux users are not as immune to security threats as many of them like to believe - anyone who has downloaded the Linux version of IRC server Unreal since November 2009 should check for a trojan. An Unreal admin said the Unreal3.2.8.1.tar.gz file on its mirrors had been replaced back in 2009 with a version …
Yes, the backdoor enables "a person to execute command with the privileges of the user running the ircd", but that's the rub. It only has the same power as that user.
It does show that linux isn't immune, but it also shows that when it IS affected, the damage is limited to the compromised component, it's not a systemwide takeover.
Also, it should be emphasised that it was only the source code that was affected. None of the binary packages have the backdoor.
"Yes, the backdoor enables "a person to execute command with the privileges of the user running the ircd", but that's the rub. It only has the same power as that user."
Or, it would be, as long as exactly zero privilege escalation exploits exist within the commands available to the process user.
This is not necessarily true:
"It does show that linux isn't immune, but it also shows that when it IS affected, the damage is limited to the compromised component, it's not a systemwide takeover."
due to the potential for escalation as mentioned above.
Well, given that this is an IRC server, I wouldn'nt expect it to need much more than a small subset of the busybox anyway; good luck finding a privilege escalation exploit in that (might exist though; probably just not too easy to find).
Also, should you get root privilege, what ya gonna do with that? Surely everyone removes make and the like as well as any other uneeded admin tool from their chroots or jails before letting them go live on the big bad 'tarwubz, no? Of course escaping chroot is not unheard of. Jail, not so much, but certainly still possible. I would not describe the process as "trivial" though, when less is your only tool.
Potential for escalation is considerably less serious than immediate compromise to an elevated user.
Most people running IRCD like this would be running on shared shell servers, where anyone can purchase an account... If unprivileged access is just $5 away then you need to ensure that privilege escalation isn't possible anyway.
Even though the IRC server and trojan would run at reduced privilege, it does get the attacker's foot in the door and allows them to then probe and exploit other possible weaknesses to escalate to root. It gets them past any firewalls and on your system where there are potentially many more vulnerabilities.
No OS is 'immune' to security threats because formal correctness cannot yet be established for anything as complicated as an entire OS. A small experimental kernel was formally proven correct recently however.
No mainstream OS even has a very high level of security.
I'm not pointing this as any particular person here but gosh our industry has a lot of clueless people to speak about topics they know nothing about.
The various reports on this problem are generally wrong on several levels. I won't go into them as I've already done that a few times and so have others.
What I will say is that methods to avoid source compromises like this are well understood and have been in use for as long as 20 years. You calculate hashes of the packages/archives (eg, using md5), keep the hashes in a seperate security domain and check them when you download. Package management systems usually automate the checking these days.
This problem occured because the people producing the package/archive didn't follow well known security procedures.
I'm glad this has happened, not because I wish Linux harm, but to highlight that all systems are vulnerable.
I am a big fan of Linux in some areas - I believe you use the OS / tools that meet your needs but have been concerned at the attitude "I use Linux so I am safe". No systems are safe - Linux may be better than Windows in many areas but *everyone* needs to be always aware of security issues.
Social engineering is the quickest way to control a system - injecting a trojan and getting users to download and install it will always be a risk.
This was not aimed at home users though, who are the ones I mostly hear repeating the mantra about *nix (and macs) being immune to all nasties. Home users don't tend to run IRC networks.
I'd bet that the majority of installs of Unreal were on servers (tastier targets for a spam/ddos network), where a higher percentage of administrators should already know that trojans can get anywhere. So this probably does nothing to raise awareness among the ignorant.
Though what this is really about is trusting your software sources, not trusting your OS.
If you install a program on your machine then, of course, it will have at least as many permissions are you (or as you explicitly allow) -- so given that this is a IRC server it's hardly any kind of vulnerability.
Last I checked Unreal IRCd ran on windows as well. It's about as much a "linux server" as Open Office is a "linux" application. If a trojan was found on windows versions of oo.org would people say that's a windows problem, or an openoffice problem?
Obviously that'd be an openoffice problem. On windows, though, it would present much more of a threat (yes, even on windows 7, which is riddled with security holes still, though they've gone a long way towards mitigating the problem) than it would on linux. Not even a well configured linux. You have to pretty badly screw things up to the point of running everything as root before something like this becomes a windows-scale threat to your system.
Big fat article FAIL.
That IS an embarrassing mistake from the Unreal team, indeed. User unreal in group unreal who has access only to the /home/unreal folder (containing only the folder with the unreal settings, and maybe some config file called .unrealrc) is going to be sooo screwed. Or not. No problem on the Linux system running the server then.
Of course the backdoor could be used to push malware towards dodgy clients installed with admin privilege on windows boxes... which would happen to connect to the compromized server... Muhahahahaha back at'ya, Doug glass!
"A warning today that Linux users are not as immune to security threats as many of them like to believe..."
First, nobody who has any sense believes that any OS is totally safe.
Second, why is it that the above sentence is wheeled out every time Linux (or an application on it) is called to task? Answer: see my first statement.
Third: Do all Linux users have any sense? Answer: Is it any likelier than users on any other OS?
Sorry, but these things happen.
It would be worse had this trojan got into the quality assured and cryptographically signed off RPM and APT software installation packages for the Linux distros out there that most Linux users actually use. If it did, that would be more serious than a single developer of a single program which isn't widely used getting hacked. Linux users/admins who install from .tgz files distributed by upstream projects should know that they don't get the same verified and integrated supply chain quality assurance if they obtain software from developers directly. The fact that it is more difficult to install from developer .tgz files is good, because those doing this should know more about what they are doing. Nothing new here about trojans, but no-one in the Microsoft world gets the extra security provided by the distribution packagers if they use 3rd party applications obtained directly from the developer
This is an issue for all OSs. Most (all?) package managers already support signing, but if you grab a tarball or zip file and run the contents that isn't going to help you on any OS. Driving a safely designed car doesn't mean you are immune to acts of stupidity.
If you admin the system it is assumed you know what you are doing. But greater use of UAC/SElinux to manage roles and more obvious enforcement of package signing would make it a bit harder for the clueless to injure themselves by installing software from random 3rd parties.
The file backdoored was the source code, not a linux binary thus this code could potentially be compiled on many different systems - not just linux..
Actually, most competent Linux users are likely to install programs like this through their package manager rather than downloading and manually compiling the source code.
It's also unlikely that a competent unix admin would compile or run something like ircd as root, thus limiting the scope of this backdoor.
Since you've already made one correction, Reg, perhaps you could make another? As several commenters have pointed out, the exploit is not in 'the Linux version of IRC server Unreal', it's in the source code. Which is, as even current Reg hacks should surely know, is not platform specific. The source of the confusion is possibly that the project appears to follow the fairly common practice of providing pre-rolled binaries for Windows but not Linux. That doesn't make the source tarball 'the Linux version', though. It's still just the source tarball. You could compile it on many platforms.
So, the story is...two-bit IRC server project gets its website compromised. Wewp, stop the presses. That must have affected, oooh, at least 20 machines. It's not like Unreal is even the most popular IRC server in the world. I mean, zoiks.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
