Slashdot Mirror
Kernel.org Attackers Didn't Know What They Had
Trailrunner7 writes "The attack that compromised some high-value servers belonging to kernel.org — but not the Linux kernel source code — may have been the work of hackers who simply got lucky and didn't realize the value of the servers that they had gotten their hands on. The attackers made a couple of mistakes that enabled the administrators at kernel.org to discover the breach and stop it before any major damage occurred. First, they used a known Linux rootkit called Phalanx that the admins were able to detect. And second, the attackers set up SSH backdoors on the compromised servers, which the admins also discovered. Had the hackers been specifically targeting the kernel.org servers, the attack probably would've looked quite different."
A few blog posts in the wake of the attack have agreed with the initial announcement; while it was embarrassing, the integrity of the kernel source is not in question.
Here is what it's referring to. CS graduates are expected to recognize instances of it instinctively.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
They must have gotten their hands on the kernel source code, I found it posted online!
Did you bother to read either of the two links in the summary about that very topic?
Basically, the nature of Git makes it very unlikely that someone could insert malicious code into the kernel via kernel.org without someone noticing.
Given that they attackers hacked the server a minimum of 17 days before it was detected, I'm not sure I'm going to buy into a story that makes the attackers sound clueless and the server admins smart and on the ball.
#DeleteChrome
That's pretty much it. Malicious control over the master copy of the kernel source means you can bake a rootkit into everything everywhere with enough clever code. All it takes is one generation of bad files to silently patch all successive copies during compilation, and you've got the stuff that cypherpunk nightmares are made of.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
I was concerned about the fact that a high profile like kernel.org site was rooted, but knowing it didn't take a sophisticated and highly knowledgeable penetration team but just a group of bumbling script kiddies makes it all better.
The first way: Haha, these skiddies didn't have what it takes to effectively hide their cracking.
The second way: Skiddies were able to crack kernel.org using automated cracking tools just Windows, no evil genius required.
AntiFA: An abbreviation for Anti First Amendment.
2-3? Mine sometimes gets hundreds. It's pretty ridiculous.these days.
I'm not a programmer, but I'm not entirely ignorant either... which leaves me with a question... Assuming that the Kernel was compromised, and the scenario you describe came into being. Isn't it just a matter of examining the Kernel code until you find the naughty bits and expunge them? Or are you basing your nightmare on this infiltration not being detected?
Not at all - the paper describes how one could write a custom C compiler which would automagically insert malicious code when it saw a particular pattern.
With a properly crafted attack you couldn't even compile your own "known clean" compiler - the attack takes advantage of the fact that most modern C compilers can't be compiled without an existing C compiler of some sort. Provided the existing compiler is the malicious one, all it needs to do is insert its own malicious payload as part of the compiler compilation process and every subsequent compiler on that system is equally malicious even though the source code is perfectly clean.
From what I read, one of the guys with a kernel.org login (HPA, I believe) had his personal machine infected by a trojan. The attackers were then able to login to kernel.org impersonating him. They then used a local-only exploit to get root.
This is why a local-only exploit is just as bad as a remote exploit. If your machine connects to a network, it has the potential to be compromised by a local-only exploit, by first exploiting a flaw in a completely unrelated program which is accessible remotely. In this case, the "flaw" was the compromised user account. It could have been a buffer overflow in an ftp or web server, which doesn't allow for privilege escalation on its own, but allows arbitrary code to be run as the current user... all the attacker has to do is make that arbitrary code trigger the local-only exploit, and your local-only exploit is now a remote one.
It's sad that so many people on slashdot keep playing local exploits down, or keep saying things like 'well it doesn't matter if my linux mail program has a flaw - the worst that can happen if I open a dodgy attachment is they wipe out my user directory, the rest of the system is safe'. Nothing is further from the truth. It's harder, yes, but not impossible to chain a bunch of vulnerabilities together so that your local-only exploit becomes remotely accessible.
This is why Linus doesn't like to classify bugs as security bugs vs other bugs. All bugs are potentially security bugs.
I'd recommend Windows instead of OpenBSD. Sure Windows has had its problems in the past but now with Windows 7 and Norton it's practically impossible to hack my systems. Even the Lunix box I run feels safer when the Windows computer is on the network. I imagine it's the firewall in Windows 7 reaching out in to the network to protect all the computers in my office.
I've been supporting Lunix and Windows at the enterprise level for many years now. I think its finally time to move away from Lunix. Linus really needs to ask himself where he wants this to go? The kernal is hacked up, probably with viruses hidden in there (we can't be sure). Sorry, I have to say bye bye to Lunix.
They didnt want to harm the kernel.
Possibly out of respect for the 11 Secret Herbs and Spices?
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office