Linux IRC Server Gets Trojan, Press Harps On Linux Security
Linked by Jordan Spencer Cunningham on Mon 14th Jun 2010 23:58 UTC
Bugs & Viruses Recently, the Linux version of UnrealIRCd was discovered to have had a Trojan worm its way into the source code. Even more embarrassing for the developers of Unreal is that the Trojan's been holding open the backdoor in the source code since November of 2009-- not very recently. And, of course, bloggers and press in general are taking the opportunity of another breach in Linux security to point out doomsday devices that don't really exist.
E-mail Print r 5   · Read More · 111 Comment(s) http://osne.ws/i3c
Thread beginning with comment 430310
To view parent comment, click here.
To read all comments associated with this story, please click here.
lemur2
Member since:
2007-02-17

Sorry, but Aristocracies is absolutely right. He has provided data to back-up the claim that the daemon is popular in its field, and (as he stated) even if the numbers of servers aren't large, the clients would be more considerable (Wikipedia has some estimate of a half-million IRC clients).

He is also correct that you went off on several tangents unrelated to the topic of potential impact of this vulnerability, calling IRC obscure, anyone who installed this incompetent, a few guesses based on total IP space, etc.

Your argument is appears incredibly weak compared to his, you may want to stop discussing this if you can't produce better formed responses that are actually on-topic.


Aristocracies is the one who went of on the tangent. It was his whole point that this IRC server daemon was somehow in his view not an obscure application, when clearly it is. It could scarcely be more obscure. Even though there is a Linux version, it is included in no Linux distribution repositories at all. I merely mentioned this in passing.

Furthermore, it truly is incompetent, both of the application authors and of anyone who installed it, to have been caught out by this trojan. There was totally no need to have been so caught out, since there are a number of means readily available to distribute Linux applications securely, so that trojans cannot get a look in. Signing the package is a very obvious thing to have done, but these developers failed to do even that. The developers even admitted to being very embarrassed by their utter lack of even the simplest security measures.

Anyone who had even the vaguest understanding of normal methods of distribution of Linux software should not have touched this particular package with a ten foot barge pole.

Unsigned binary packages simply downloaded from a server and manually installed is the absolutely classic vector for trojan horse malware injection.

http://en.wikipedia.org/wiki/Trojan_horse_%28computing%29
Trojan horses can be installed through the following methods:
* Software downloads (e.g., a Trojan horse included as part of a software application downloaded from a file sharing network)


I'm sorry, but this is in the very first page of security 101 for dummies ... don't do this. Don't do unsigned binary installation packages. Refuse point blank to ever install such things.

Edited 2010-06-16 11:51 UTC

Reply Parent Score: 2

saynte Member since:
2007-12-10

I don't see how this is obscure. Your own Wikipedia link states that the top 100 IRC servers alone host over a half million users at a time. With at least a half-million users, how can it be so obscure? Clearly a vulnerability to the servers translates to a problem for the clients.

Reply Parent Score: 1

chris_l Member since:
2010-02-14

I don't see how this is obscure. Your own Wikipedia link states that the top 100 IRC servers alone host over a half million users at a time. With at least a half-million users, how can it be so obscure? Clearly a vulnerability to the servers translates to a problem for the clients.


It's obscure because *PRETTY MUCH NOBODY USES IT UNDER LINUX*

GET THE CONCEPT THOUGH YOU PIN-SIZED BRAIN,PINHEAD.

Reply Parent Score: 0

Aristocracies Member since:
2010-06-15

You still haven't grasped the fact that this trojan wasn't in an executable binary. None of the provided executable binaries were infected, in fact, they only provide a Windows binary. Someone had replaced the source tarball with one that had the backdoor in the source code itself. This allowed anyone who built the daemon to have anyone connected to the IRC service execute arbitrary commands as the user the daemon ran as. The potential for abuse there if one was motivated is mindboggling, since it'd be trivial to take control of the entire service from that point.

Anyone who downloaded this and compiled it had an issue. In fact, all the fix scripts for this are simply cleaning a header file, then you have to recompile. Or you could just grab a known clean tarball now and check against the provided hashes.

Sure, they should have been doing more and in fact, now are. But you're still a crazed autistic who can't be bothered to read anything to get his facts straight. I'm sure your reply will be more drivel attacking the Unreal team and then some further distractions like 'hurr tarballs are binaries too', all of which you're throwing forth because someone wrote a mean article about your preferred OS, even if no one in their right mind would take said article seriously. ;)

Edited 2010-06-16 19:17 UTC

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

You still haven't grasped the fact that this trojan wasn't in an executable binary.


Correct. It was in an unsigned binary file, which was a tarball of the application source code. What exactly was it that you contend that I did not grasp?

None of the provided executable binaries were infected, in fact, they only provide a Windows binary. Someone had replaced the source tarball with one that had the backdoor in the source code itself. This allowed anyone who built the daemon to have anyone connected to the IRC service execute arbitrary commands as the user the daemon ran as.


Exactly. This is a classic trojan horse. Where did I say anything different? (PS: a tarball is a binary file, it is not a plain text file, although it can contain plain text files).

The potential for abuse there if one was motivated is mindboggling, since it'd be trivial to take control of the entire service from that point.


For up to the Linux subset of some 800 IRC server machines, of all the machines on the entire Internet. Obscure.

Anyone who downloaded this and compiled it had an issue.


And ran it. Apparently this could amount to maybe 300 machines, perhaps.

In fact, all the fix scripts for this are simply cleaning a header file, then you have to recompile. Or you could just grab a known clean tarball now and check against the provided hashes. Sure, they should have been doing more and in fact, now are.


Now that they are using standard practice, the trojan is no more. Agreed.

But you're still a crazed autistic who can't be bothered to read anything to get his facts straight. I'm sure your reply will be more drivel attacking the Unreal team and then some further distractions like 'hurr tarballs are binaries too', all of which you're throwing forth because someone wrote a mean article about your preferred OS, even if no one in their right mind would take said article seriously. ;)


Sigh!

Oh dear oh dear. Tarballs are indeed binaries. Type "cat name-of-tarball.tgz" at a command prompt and see for yourself.

In order to avoid trojans, standard practice to distribute tarballs of software source code is to provide checksums and a PGP/GPG signature along with the tarball.

Like so:
http://www.ffmpeg.org/download.html
(Provides a source tarball, MD5 and SHA1 checksums, and a PGP signature).

UnRealIRC failed to do this simple thing, which is accepted standard practice. I'm afraid that under any viewpoint at all, that makes them incompetent. Likewise for anyone who accpeted their unsigned file and put it in their distribution, namely Gentoo and Arch Community repo.

Following accepted standard practice, which is very simple to do, would have avaoided this breach of security entirely. There is no excuse, really.

Reply Parent Score: 2

Read more of this thread... >