Linux optimize

Linux repository hit by malware attack

The kernel.org Linux repository was rooted by a malware attack. While the breach goes under investigation, the websites for kernel.org, Linux Foundation, and Linux.com are down for maintenance.

A particularly ugly attack originating on kernel.org drove the Linux Foundation and Linux.com to close down its sites for maintenance. Here is part of the message posted on the Linux Foundation website:

Linux Foundation infrastructure including LinuxFoundation.org, Linux.com, and their subdomains are down for maintenance due to a security breach that was discovered on September 8, 2011. The Linux Foundation made this decision in the interest of extreme caution and security best practices. We believe this breach was connected to the intrusion on kernel.org.

The Register reported on the kernel.org intrusion on Aug. 31, stating that the infection went undetected for at least 17 days.

Multiple servers used to maintain and distribute the Linux operating system were infected with malware that gained root access, modified system software, and logged passwords and transactions of the people who used them, the official Linux Kernel Organization has confirmed.

According to security researchers who commented on the attack to The Register, the malware was a self-injecting rootkit, known as Phalanx, that first took hold on kernel.org developer H. Peter Anvin's personal machine, then appeared on kernel.org servers Hera and Odin1, where a "secure shell client used to remotely access servers was modified, and passwords and user interactions were logged during the compromise."

Kernel.org is also down, but posted a note earlier that they are working on having all of its 448 users to change passwords and SSH keys. As far as the damage that was done, that is still being assessed, although some are offering reassurance. PC World quotes kernel.org's message that "the potential damage of cracking kernel.org is far less than typical software repositories" because the cryptographically secure SHA-1 hash that is used to define files would alert developers to any tampering.

What do you think -- do you trust that the Linux kernel will be safe and sound after the investigation is completed?

About

Selena has been at TechRepublic since 2002. She is currently a Senior Editor with a background in technical writing, editing, and research. She edits Data Center, Linux and Open Source, Apple in the Enterprise, The Enterprise Cloud, Web Designer, and...

12 comments
gteachey
gteachey

You're not proving you're mainstream until the hackers take the time to try and exploit your machines. :) Just saying, why bother if no one's going to notice the attack? Am I right? Right!

greenpoise
greenpoise

This is the first time in my 13 plus years working with Linux that I see that there has been a "malaware" attack in the kernel let along Linux. Why is this such a headline when Microsoft servers & users pc's get exploited each day with all sorts of crapWares??? I know US economy needs to get back on track and Microsoft is one of those big corps but common, what a cheap shot honestly...such a cheap shot...This headline was only at this site, znet and other commercial MS sites..very disappointing...

flhtc
flhtc

Reading through the comments here the general thoughts are about the kernel files, etc. As stated, the breach went undetected for 17 days. If the afore mentioned security they have in place was doing it's job AND the intruders were there to alter the content, I would think that it would not have taken over 2 weeks to find out. They could have been there for 100 other reasons. On the other hand they could have been going for some obscure pieces of code hoping they wouldn't get noticed. Isn't that a scary thought. Bottom line, I hope that the kernel.org folks are not concentrating solely on the content, but I'm sure they're smarter than that. my .02c

pgit
pgit

...that all the hoopla over 'which is better, Linux or windows' is a waste of time. It doesn't matter how safe the OS is when you have vulnerable apps exposed to the world. I can't count the number of times I tried to point out that with all the UNIX/Linux exploits we've seen, the OS has actually been doing it's job splendidly; it's doing exactly what it's being told to do. It's just being told to do malicious, unintended things. In contrast, many windows exploits do alter the OS itself, not just an app running on top of it. But again it doesn't matter, it's some app, often with an end user using that app, that gets to malware ball rolling. Whatever the OS happens to be is relatively immaterial.

billyg
billyg

This will likely strengthen the Linux community. I think the more interesting speculation here is who may have perpetrated the breach. Since the code is open that eliminates theft as the motive... leaving trophy hunting or the desire to inject a Trojan...

Editorial_Response
Editorial_Response

Since those sites, kernel.org, Linux Foundation, and Linux.com, are the root site for kernel development of so many strtagically important systems you would think that for all files systemwide, they would use two hashes on everything. LIke an md5 and a sha1. By using hashes from different families of logic it makes it harder to find a collision space. Just my $0.02.

gabriel.tate
gabriel.tate

Speaks volumes to the stability of the Linux Kernal since this is news. As an administrator of an all Microsoft Network and frequently use military network computers...... I have so many security pop-ups and email marking tools that pop up that I think the Malware would have less of an iimpact on my workday.

Neon Samurai
Neon Samurai

Granted, I suspect most of the kernel.org folks have probably seen at least one breach in the past but sometimes you need the reminder for why one should be paying attention to servers and to personal machines. As for any risk to the Linux source code.. nearly a non-issue. There are so many layers of hashing in place that any modification is going to be noticed. Everything is signed indavidually. Kernel developers all have mirrored repositories on there own systems which provide yet another validation or base to identify modification. Distributrions are also not pulling the latest kernel source and shipping it to end users so a worst case currently only affect folks who download direclty from kernel.org to roll there own. Not something to be dismissed outright either. Unless your a kernel.org member, may as well grab the popcorn and see how it all plays out.

todd_dsm
todd_dsm

Only non-technical managers and Microsoft would do silly things like patch an OS, then create a new OS without all previous patches, then repeat the patching process. Developers create test cases and save them forever. These guys let their guard down, to be sure, but they will fix it and so it shall remain till doomsday. Or until they get caught with their pants down again. Besides, a little embarrassment is good for the soul; it reminds us not forget our frailties and maintains a modicum of humility. They'll get over it just fine.

Neon Samurai
Neon Samurai

That may be the answer to your question right there. It happens on Windows systems every day; it's not news. It has to be something interesting like Morto which is special because it uses DNS for command/control and does not currently exploit a code vulnerability to propogate (it just tries to log in like any other remote terminal user would). Apple gets it pretty bad too. Every blunder that conflicts with the Apple utopian marketing message. I'm actually surprised by the lack of "nah nah" comments by other OS fans.

Neon Samurai
Neon Samurai

I'm trying to find the original article I read on it. In development, each file is signed so that if a non-dev change is made, the next dev to sync there local repository with the official repo gets a screen full of error messages (hey.. this file does not match it's hash value..). Once the kernel version is released as the current production version, the entire source tree gets signed along with the consolidated collection of per-file hash values being signed. Any change in the source breaks the file hash and overall tree hash. Now, here's where we get to distributions (how most folks get ther kernel source/binary). Not all distributions are equal and how a distro manages it's repository packages is indeed a defining and competitive attribute. If your distro is taking the kernel.org development source and hadning it to you as the official production release for the distribution; find a new distribution unless running development code is your intention. The distro should be giving you a production version of the kernel which means they can verify against a frozen source tree and it's stack of inter-reliant hash values. It seems that the current house of cards built out of each production version's hash values is comprehensive enough to identify unofficial changes. Maybe building a second house of cards out of each source tree with a secondary hash algarythm would increase identification of changed files though.

pgit
pgit

I've never thought of that before... now you got me wondering if something like kerberos and ldap could work in tandem. :)