Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Backdoor Found In UnrealIRCd Source Archive

timothy posted more than 4 years ago | from the channel-is-pwn3d dept.

Security 174

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

cancel ×

174 comments

Sorry! There are no comments related to the filter you selected.

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

allaunjsilverfox2 (882195) | more than 4 years ago | (#32554866)

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. (3, Insightful)

Abcd1234 (188840) | more than 4 years ago | (#32554872)

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

PAN - PURE AFRICAN NIGGER (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32554916)

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

niggers and coons, niggers and coons, niggers and fucking coons.

porchmonkey apeman mooncricket jigaboo darkie kneegrow

what does it say on the inside of a nigger's lips? INFLATE TO 30 PSI

niggerlips

Racism (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32555464)

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

Somewhat related...the results from Google's "auto-suggest" feature:

Typing in "Michelle o" brings up "michelle obama monkey" as the 7th choice.
typing in the additional letters Michelle o"b...a...m...a" brings up "michelle obama monkey" as the 6th choice.
Hitting the space bar after that brings up "michelle obama monkey" as the 5th choice.

Typing in "Michelle Obama m" brings up "michelle obama monkey" as the 1st choice.
Typing in "Michelle Obama g" brings up "michelle obama gorilla" as the 8th choice.

Ergo, Google is the devil...no, wait. We're the devil...and it feels good...so good.

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

davester666 (731373) | more than 4 years ago | (#32554926)

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.

Re:It's nice that they're honest. (0)

Anonymous Coward | more than 4 years ago | (#32554952)

Paranoid much?

Re:It's nice that they're honest. (2, Funny)

Narcocide (102829) | more than 4 years ago | (#32555630)

Seriously, that's what you call unchecked paranoia. Nobody is ordering Microsoft grunts to sabotage open source software. They do that in their free time for fun.

Re:It's nice that they're honest. (0, Offtopic)

TheRaven64 (641858) | more than 4 years ago | (#32555738)

You're in the wrong article. The one about autism is a few further down the front page. In this one, you're supposed to have a sense of humour or, if you're American, a sense of humor.

Re:It's nice that they're honest. (2, Funny)

drinkypoo (153816) | more than 4 years ago | (#32556716)

You're in the wrong article. The one about autism is a few further down the front page. In this one, you're supposed to have a sense of humour or, if you're American, a sense of humor.

That's it, I'm headed to the autism article to make a joke. Wapner, here I come!

Re:It's nice that they're honest. (0, Offtopic)

Anonymous Coward | more than 4 years ago | (#32555138)

if you are referring to google collecting wifi data, google has no credible defense. grab a linux distro, mapping ssid is a matter of a 3 lines script. If they bothered to use more code, some evil is involved.

 

Re:It's nice that they're honest. (0, Offtopic)

Anonymous Coward | more than 4 years ago | (#32555324)

if you are referring to google collecting wifi data, google has no credible defense. grab a linux distro, mapping ssid is a matter of a 3 lines script. If they bothered to use more code, some evil is involved.

He might also be referring to the belief some people seem to have that Google voluntarily disclosed this without any outside pressure. The fact is that they only disclosed this after European governments started demanding auditing the data the cars collected.

Re:It's nice that they're honest. (3, Insightful)

jibjibjib (889679) | more than 4 years ago | (#32555474)

Maybe (in fact, almost certainly) Google wanted to capture every packet, measure its signal strength and collect statistics to get more detailed maps of wireless networks than what a simple "3 lines" script would provide. Why would you discount that as not being "credible", but instead accept the even more incredible possibility that (despite until now being a legitimate business) they're involved in some sort of international conspiracy to illegally use random people's private wi-fi data?

A common way of mapping wireless networks is using software like Kismet, which is in fact what Google used, and which in its default configuration saves all packets received. If you claim it must be true that "some evil is involved" because they used standard widely used software rather than your 3-line script, you don't know what you're talking about.

Re:It's nice that they're honest. (0, Offtopic)

DaveV1.0 (203135) | more than 4 years ago | (#32556188)

Unless, of course, one were hoping to use SSID + Signal strength to try to determine the user's position without accessing the WiFi network. You know, like what happens with Android phones.

Re:It's nice that they're honest. (0)

Anonymous Coward | more than 4 years ago | (#32555384)

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

If that were true, wouldn't that make you Steve Ballmer, and thus a Billionaire?

Doesn't sound so bad too me.

Re:It's nice that they're honest. (1)

poppycock (231161) | more than 4 years ago | (#32554950)

Well, perhaps it was an inside job...

Re:It's nice that they're honest. (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32555068)

Well, so much for the so-called open source philosophy being better...

Re:It's nice that they're honest. (4, Informative)

Lobachevsky (465666) | more than 4 years ago | (#32555130)

Closed source software has similar problems with disgruntled employees. Only difference is that the company when finding the backdoor quietly fixes it and gags anyone from going to the media about it.

Re:It's nice that they're honest. (1, Interesting)

the_womble (580291) | more than 4 years ago | (#32555140)

Yes, because a single trojan in a server that:

1) no one uses (not a single user checked the hash of the download over seven months),
2) is not in the repos of most distros,
3) was not included in the Debain repos, despite there being a willing maintainer, because of poor code quality- see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130 [debian.org]

completely refutes all the different arguments in favour of open source (many eyeballs, multiple vendors to provide free market competition, no lock in, etc).

We all know that not one single proprietary app has ever had a security issue.

Re:It's nice that they're honest. (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32555190)

Yes, because a single trojan in a server that:

1) no one uses (not a single user checked the hash of the download over seven months),

The hashes most probably _where_ checked by peopel, however they've been changed to reflect the backdoored .tar.gz on the website.

This is from the horses mouth a.k.a. Syzop:

[12:30:04] well the main site got hacked huh, so the md5sum on the website was reflecting the trojanized version
[12:30:18] but nobody checked the md5sum against the one mentioned in the announcement

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

keeboo (724305) | more than 4 years ago | (#32556012)

3) was not included in the Debain repos, despite there being a willing maintainer, because of poor code quality- see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130 [debian.org]

The lack or presence of a software in Debian does not mean anything about its quality.
Unfortunately there are are people, among the Debian devel, who are more political assholes than proper developers.

An example of utter garbage present in Debian is pdns [debian.org] (the software itself collapses after running for few hours, even minutes, depending on your load). Yet, each new Debian release contains a new version of that software. -- And that's not the only case.

Re:It's nice that they're honest. (1)

DaveV1.0 (203135) | more than 4 years ago | (#32556254)

1) no one uses (not a single user checked the hash of the download over seven months)

Logic fail, does not follow. Just because the hash has not been checked (which it might have been as the attacker could have replaced the hash on the server as well as the code), it does not follow that no one uses or no one has downloaded the code. The "many eyes" claim results in a false sense of security.

Re:It's nice that they're honest. (2, Insightful)

Vahokif (1292866) | more than 4 years ago | (#32555188)

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. (4, Insightful)

Runaway1956 (1322357) | more than 4 years ago | (#32555334)

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

Re:It's nice that they're honest. (4, Informative)

lorenzo.boccaccia (1263310) | more than 4 years ago | (#32555382)

1 it was not a screwup it was an intentional attack:

"It appears the replacement of the .tar.gz occurred in November 2009"

2 as far as exploit goes, this is pretty limited:

"This backdoor allows a person to execute ANY command with the privileges of the user running the ircd. The backdoor can be executed regardless of any user"
  - who is actually running a irc demon as root?

3 IT WAS NOT IN THE SOURCE

"CVS is also not affected."
  - they substituted the archive

Re:It's nice that they're honest. (1)

jibjibjib (889679) | more than 4 years ago | (#32555486)

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. (0, Redundant)

DaveV1.0 (203135) | more than 4 years ago | (#32556198)

How about embarrassing as in "We have been claiming shit like this can't happen to us because we are open and everyone can look at the code and any change will be found and fixed quickly and this compromised code has been sitting out there for 8 months and no one noticed!"

Re:It's nice that they're honest. (2, Interesting)

Kjella (173770) | more than 4 years ago | (#32556522)

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 diffs so that's not very subtle either.

But then there's the downstream and binary builds. A few packagers, mirror maintainers and distro maintainers might look at these but hardly anybody else. A good example is the Debian OpenSSL fiasco [slashdot.org] a few years back. There's this one, that got caught. How many of these go unnoticed? How many really checks that nothing bad happened between the upstream VCS and the binary running on my server? How many makes sure the source and binary posted really match and compile to the same MD5 and won't just disregard it as different compiler versions and flags? Extremely few. Like in this case, it was no good checking the MD5 because it was also compromised...

Re:It's nice that they're honest. (1)

LO0G (606364) | more than 4 years ago | (#32556726)

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:It's nice that they're honest. (1)

GooberToo (74388) | more than 4 years ago | (#32556730)

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 morale doesn't have anything to do with obscurity. The morale is, don't release anything and everything simply because it was committed. Find me any developer who subscribes to the merge/release everything, without any sort of review, and I'll show you an unfit developer - without fail.

In open source projects, like say the Linux Kernel, this stuff doesn't happen because people care what is being committed, merged, and released. This is FAR more a condemnation of the project and the developers in charge than it have anything to with open source. In short, if you ever needed an excuse to never use their code, now you have it. Unless lots of heads role, rest assured this type of stupidity is very likely to happen again with this project.

Re:It's nice that they're honest. (2, Interesting)

indeterminator (1829904) | more than 4 years ago | (#32555726)

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:It's nice that they're honest. (1)

grumbel (592662) | more than 4 years ago | (#32555766)

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 projects do, the second part would however require that we stop using tar or at least wrapper it up to make the signature check an automatic thing of the extraction process. As long as the GPG check is thing that you need to take care of manually, most people will just never do it.

Re:It's nice that they're honest. (0)

Anonymous Coward | more than 4 years ago | (#32556034)

and as long as the GPG check is a thing that happens automatically, it too can be easily compromised.

However, having the main site run automated checks to esure that the archives it serves are properly signed /would/ make sense.

Re:It's nice that they're honest. (1)

segmond (34052) | more than 4 years ago | (#32555250)

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 audited triple times over.

Re:It's nice that they're honest. (1, Informative)

Anonymous Coward | more than 4 years ago | (#32555938)

There is no need to audit the entire source, because the CVS wasn't affected. It is actually quite clever to put the backdoor only into release tar balls, because the "many eyeballs" that open source is famous for typically only look at the original source, i.e. the main repository.

Remember, kids! (0)

Voulnet (1630793) | more than 4 years ago | (#32554868)

Always check the hash signatures of any application you use, or at least any application you wish to give internet access to!

Re:Remember, kids! (1)

GigaplexNZ (1233886) | more than 4 years ago | (#32554908)

I'm not quite sure how that would help as this was built directly into the source so the official blessed hash that you are comparing against is compromised.

Re:Remember, kids! (5, Informative)

Stupendoussteve (891822) | more than 4 years ago | (#32554936)

Actually, the hash was not modified from when they posted the true source. Anybody who would have checked it would have recognized that something was wrong.

Re:Remember, kids! (1)

Peach Rings (1782482) | more than 4 years ago | (#32555134)

Haha, nobody ever checks hashcodes. It's only a matter of time before like 10 million users install something and NONE of them checked the hash code !

Re:Remember, kids! (0)

Anonymous Coward | more than 4 years ago | (#32555348)

I just about always check the hashcodes just to make sure the download was successful. I'm less careful about checking GPG signatures than I should be...

Re:Remember, kids! (0)

Anonymous Coward | more than 4 years ago | (#32555640)

I always check them too, mainly to check for corrupted downloads.

Re:Remember, kids! (1)

FrangoAssado (561740) | more than 4 years ago | (#32554986)

From the post in the forum, it seems that only the source tgz in the mirrors was affected. So, anyone who checked the MD5 agains the official (non-mirrored) tgz would realize the difference.

Apparently, no one bothered to check for a long time, though.

Re:Remember, kids! (1)

asdf7890 (1518587) | more than 4 years ago | (#32555162)

Apparently, no one bothered to check for a long time, though.

Or perhaps the people that did check just assumed that the genuine uploaders forgot to include/update the hashes so that the difference was due to the hash being for the previous (or earlier) version. Though in that case you'd expect the sort of person who would check official hashes would be the sort who would report the discrepancy upstream (or at least ask about it on an official forum).

Re:Remember, kids! (1)

GigaplexNZ (1233886) | more than 4 years ago | (#32555304)

From the post in the forum, it seems that only the source tgz in the mirrors was affected.

Fair enough, the site was /.ed when I looked so I wasn't able to glean that information

Re:Remember, kids! (0)

Anonymous Coward | more than 4 years ago | (#32554918)

If they had access to the "Source Archive", why wouldn't they just change the signatures to something that matches?

Re:Remember, kids! (1)

mysidia (191772) | more than 4 years ago | (#32555166)

Just because you have a MD5 signature, does not mean it's any good. Always verify the PGP signature.

According to some reports that were made by people on IRC Security related discussion forums:

"The unreal site was listing the backdoored md5 as official."

In addition, there were gentoo ebuilds using the trojanned source's signatures, and trojanned sources on Gentoo mirrors

Re:Remember, kids! (0)

Anonymous Coward | more than 4 years ago | (#32555374)

As a Gentoo user, I hope this leads to an audit of all packages. At the time of this post I verified that gentoo ebuild package system had a manifest containing checksums of the bad archive and has so at least since December 21st 2009.
The great part of this is that 3.2.8.1 was quickly stabilized (except on amd64) because of a dos in 3.2.7. WTG guys.

Re:Remember, kids! (1)

Stupendoussteve (891822) | more than 4 years ago | (#32556260)

This is one of the reasons I do not 100% trust a package manager. Sure, it is more secure than downloading from a random site, but there is very little stopping an upstream security issue (or even malicious author) from making it into the mirrors, and I don't trust that all distro developers are checking that the hashes match either.

Open source (0, Troll)

MrNaz (730548) | more than 4 years ago | (#32554880)

The fact that this can get into the program is a weakness of the open source model. The fact that it can be found so quickly is a strength of the open source model.

Re:Open source (3, Insightful)

Stupendoussteve (891822) | more than 4 years ago | (#32554946)

How is it a weakness? It's a weakness of the admin, but being open source didn't somehow make it easier to get malicious code into the source. People could just as easily hijack a binary file (and there's a good chance it would go unnoticed for a longer time).

Re:Open source (2, Insightful)

MrNaz (730548) | more than 4 years ago | (#32555062)

I'm implying that anyone who manages to get commit rights, or even a contributor who's good as obfuscating code, could implant a backdoor into a project. Remember the Debian SSL fiasco? Well, that sort of thing could happen maliciously. In a closed source development environment it's harder (note, I didn't say impossible) to get this sort of thing in, as the effort and/or expense required to inject a mole into the developer circle is higher and the personnel are typically more carefully vetted.

However, the strength of open source is that there are many people looking over each others' shoulders. In a closed source environment, if you manage to get your mole into an area of code development where there are only a small number of developers, well-hidden and obfuscated malicious code could stay buried potentially forever, as once those few guys move on (and they will in corporate land), nobody who comes after then will aggressively pursue legacy code as they won't want to break anything that's already working. Nothing short of a full code audit will catch it.

And thank you for making me explain myself in full.

Re:Open source (1)

bhtooefr (649901) | more than 4 years ago | (#32555746)

This wasn't commit rights.

This was attacking the mirrors.

You can do the same exact thing to closed source software, by infecting the binary with a malware installer.

many eyeballs Mirkwood forest (1)

epine (68316) | more than 4 years ago | (#32556408)

There's really no technical excuse for not catching a deviation between a release point in a VCS system and the associated tarball, assuming the VCS hasn't also been compromised.

Given this statement, the sensible eyeballs are validating the source as it exists in the VCS, and the sensible admins are checking the correspondence of the tarballs downloaded against the associated VCS checkout checksum. I'm not saying this is the procedure most sites us, just that there's no conceptual obstacle to making this happen. The locus of trust is the VCS system, not the derivative tarballs.

It's the stupidest thing I've heard in a long time to think that open source has such a surfeit of competent eyeballs that they can afford to scatter their resources and catch deviations everywhere, including purportedly identical copies.

That's putting a value of zero on a competent eyeball. Competent eyeballs are contributing to the project, and noticing defects on an incidental basis. This incidental attention catches a lot where activity is heavy.

Vandalism on obscure Wikipedia pages often survives for months, if more subtle than replacing the entire page with

$favorite_underutilized_part_of_my_anatomy!

The concept of scattering this kind of precious scrutiny over derivative works because software installers are too damn lazy to check the shasum boggles my mind.

I end up installing quite a lot of software in the middle of trying to complete a complex task under deadline. Many times I've closed my eyes and typed "sudo make install". When I'm less under the gun I'm more deliberate in my approach. Apparently my faith in distributed paranoia is largely unfounded.

Or maybe the people setting up IRC servers have some dim thought in the back of their minds "maybe I'll meet a chick and get laid someday". There's nothing like the mating reflex to dampen the precautionary spirit.

Proposed warning for the download page:

The bad news is that this software won't help you get laid. The good news is that if you neglect to check the shasum, you might catch a vicarious STD anyway.

Re:Open source (5, Informative)

tsj5j (1159013) | more than 4 years ago | (#32554972)

Read the original linked source. The source repositories were not compromised; rather, the mirror servers were. The mirror servers had the tarballs replaced with malicious code.

Re:Open source (0)

Anonymous Coward | more than 4 years ago | (#32555848)

Many eyes (too busy staring at porn to notice the malicious code)

Windows safer than linux (2, Funny)

nicknamesarefunny (1810810) | more than 4 years ago | (#32554882)

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:Windows safer than linux (2, Insightful)

Rijnzael (1294596) | more than 4 years ago | (#32555006)

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.

Re:Windows safer than linux (1)

mysidia (191772) | more than 4 years ago | (#32555174)

The windows provided BINARIES were not effected. If you compiled the windows version from source code, it was also effected.

Re:Windows safer than linux (1, Informative)

Anonymous Coward | more than 4 years ago | (#32555276)

No, the Windows binaries were not affected. If you compiled them, they would have been affected.

Re:Gentoo (Linux) not affected (1, Informative)

miknix (1047580) | more than 4 years ago | (#32555824)

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 the UnrealIRCd maintainer at Gentoo digitally signed the infected tarball. But developers at Gentoo have a lot of experience, so I suppose most everyone checks the hash of tarballs after download. At least I do..

Re:Gentoo (Linux) not affected (2, Informative)

Anonymous Coward | more than 4 years ago | (#32555980)

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.

Only some versions affected (2, Informative)

jaak (1826046) | more than 4 years ago | (#32554922)

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.

The remediation advice is wrong (2, Insightful)

poppycock (231161) | more than 4 years ago | (#32554938)

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:The remediation advice is wrong (2, Insightful)

Stupendoussteve (891822) | more than 4 years ago | (#32554962)

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

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

poppycock (231161) | more than 4 years ago | (#32554976)

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

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

mysidia (191772) | more than 4 years ago | (#32555178)

May I remind you that the Windows binaries are unaffected?

Re:The remediation advice is wrong (0)

Anonymous Coward | more than 4 years ago | (#32555186)

I think for most irc server admins it isn't the box they are worried about losing integrety on so much as the network it connects to.

Re:The remediation advice is wrong (1)

cbhacking (979169) | more than 4 years ago | (#32555420)

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.

Re:The remediation advice is wrong (0)

Anonymous Coward | more than 4 years ago | (#32555496)

You install unreal as a regular user. For that matter, in my case, i run all irc related apps (qwebirc, anope and unreal) on a seperate account, which nothing else runs on, though its mainly as a housekeeping procedure, and none of those need elevated rights to install or run.

Re:The remediation advice is wrong (1)

jibjibjib (889679) | more than 4 years ago | (#32555506)

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

Re:The remediation advice is wrong (1)

X0563511 (793323) | more than 4 years ago | (#32555604)

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

Re:The remediation advice is wrong (1)

cbhacking (979169) | more than 4 years ago | (#32555662)

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 Windows or possibly Mac OS) software installation is something done as Admin/root, almost by definition.

Re:The remediation advice is wrong (0)

Anonymous Coward | more than 4 years ago | (#32555762)

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

Are you really implying that using the package manager indicates a reduction in savviness?

Re:The remediation advice is wrong (2)

PiAndWhippedCream (1566727) | more than 4 years ago | (#32554968)

LiveCD.

Re:The remediation advice is wrong (1)

poppycock (231161) | more than 4 years ago | (#32554996)

Yeah, LiveCD is an option if you have it.

Re:The remediation advice is wrong (1)

DarkOx (621550) | more than 4 years ago | (#32555982)

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.

Backdoor allows user to execute ANY command (2, Funny)

qubezz (520511) | more than 4 years ago | (#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

Re:Backdoor allows user to execute ANY command (1)

mysidia (191772) | more than 4 years ago | (#32555204)

Sure, but that would be almost benign, compared to other possibilities -- bad guys having newly acquired access to the IRC server, could move to link rogue servers in, intercept user traffic, and more effectively generate mass ads for malware-infested websites, while getting users' NickServ passwords all at the same time?

Re:Backdoor allows user to execute ANY command (1)

caluml (551744) | more than 4 years ago | (#32556264)

It'd be nice if all IRC servers spoke a common protocol - then a network could use a variety of different IRCds.
I migrated from Unreal to Inspircd about a year ago (phew), and it was a problem. I had (until then) assumed that the IRC linking protocol was a common protocol (like SMTP or XMPP). Oh no.
So, to all the IRC software people - get together, and standardise on a single format. You can have an "extensions" section in the protocol for your specific additions, but make it a general, federated protocol.

Kinda funny.... (0)

Anonymous Coward | more than 4 years ago | (#32555114)

AVG reports a front page link as the highest risk it reports :P

Well yes... (5, Insightful)

Anonymous Coward | more than 4 years ago | (#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).

Re:Well yes... (1)

kthreadd (1558445) | more than 4 years ago | (#32555388)

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 without superuser privileges. The fact that we are basically forced to run them as such is much worse than the false sense of security that the 1024 port limit gives us.

Re:Well yes... (1)

jibjibjib (889679) | more than 4 years ago | (#32555524)

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:Well yes... (2, Informative)

bstreiff (457409) | more than 4 years ago | (#32556310)

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.

Re:Well yes... (2, Insightful)

X0563511 (793323) | more than 4 years ago | (#32555614)

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... (3, Insightful)

caluml (551744) | more than 4 years ago | (#32556286)

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.

Re:Well yes... (0)

Anonymous Coward | more than 4 years ago | (#32556206)

Yusuf, is that you?

Well (1)

trifish (826353) | more than 4 years ago | (#32555332)

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

Re:Well (0)

X0563511 (793323) | more than 4 years ago | (#32555616)

Even so, often the more efficient way is to sign the hash.

If nobody cares enough to verify the hash, what makes you think they will verify the signature?

Re:Well (1)

cbhacking (979169) | more than 4 years ago | (#32555672)

You can add a small layer of security (easily bypassed if the attacker knows where to look, but still...) by placing the hash and/or signature verification in your installer. Add something to the config scripts, or possibly to your makefile. If you offer pre-built packages, it's even easier.

Re:Well (1)

DaveV1.0 (203135) | more than 4 years ago | (#32556140)

Sounds to me like you are suggesting security through obscurity. Isn't that something that gets soundly derided here on slashdot when used in proprietary code? Why, yes, yes it is.

Re:Well (1)

cbhacking (979169) | more than 4 years ago | (#32556620)

What I'm suggesting is part of a defense in depth. You can't rely on security through obscurity, but obscurity can provide some assistance. The concept that security through obscurity is fundamentally flawed comes from encryption/hash algorithms, which are so complex that attempting to cook your own in secret is likely to result in something that is actually easier to crack - even though you either must first reverse-engineer how it works or just use brute force - than a published and thoroughly reviewed, tested, and revised algorithm.

I say again, a small layer of security; it's not something you can rely on, alone, but it is something that will stop a careless attacker and will take some time from a knowledgeable one, for very little cost on your part.

Re:Well (2, Insightful)

trifish (826353) | more than 4 years ago | (#32556026)

the more efficient way is to sign the hash.
Digital signatures actually ARE signed hashes. So I'm not sure what you're trying to invent there (and how it would be more efficient).

Re:Well (1)

naplam33 (1751266) | more than 4 years ago | (#32555918)

Nobody checks the signatures. But yeah, somebody would eventually have noticed in 1.5 years and told the maintainers if they had signed the packages.

Re:Well (0)

Anonymous Coward | more than 4 years ago | (#32555950)

It's not my problem. I check them. But most importantly, if only 1% of users checked them, then it wouldn't take more than ~100 downloads before someone noticed and alerted the authors.

(Posted as A/C because I'm not interested in replies from someone as stupid as you.)

Whew! (1)

Katchu (1036242) | more than 4 years ago | (#32555400)

That's what I like about open source. Eventually things get found out.

Re:Whew! (0)

Anonymous Coward | more than 4 years ago | (#32555472)

Even if it takes 8 months with an MD5 that doesn't even match.

Re:Whew! (1)

DaveV1.0 (203135) | more than 4 years ago | (#32555974)

Yes, because this could have happened to closed-source software and no one would have known and it would never have been found.

Oh wait, we know that to be false.

This happened specifically because UnrealIRC is open source. And, let us not forget that many flossies love to talk about how such things as this can't happen because so many people are looking at the source code.

Re:Whew! (1)

Datamonstar (845886) | more than 4 years ago | (#32556096)

No one with any real clout in the OSS industry has ever claimed that OSS is 100% free of evil code simply because it's open. What usually happens is exactly what happens here, the problem is discovered and disclosed to the community. Now how different that is from a closed-source offering I don't know because I've never worked with anything like that. But with open source the code is there and you're free to review it if you want to and know how.

Re:Whew! (1)

DaveV1.0 (203135) | more than 4 years ago | (#32556118)

Yes, it only took a YEAR for it to be found.

But with open source the code is there and you're free to review it if you want to and know how.

You forgot that the person also has to have the time and resources, which most normal people don't have. The SAs and programmers where I work don't have the time to download and review the source of every bit of free software used in the company. And, I could do it for my personal systems, but I don't know C, C++, Python, and every other programming language used for the software and even if I did, I would not want to give up my free time to do that.

The claim that FLOSS is more secure because of "many eyes" is just as bogus as security through obscurity.

Re:Whew! (1)

DaveV1.0 (203135) | more than 4 years ago | (#32556128)

Excuse me HALF A YEAR.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>