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!

Kernel.org Attackers Didn't Know What They Had

Soulskill posted more than 2 years ago | from the you-never-appreciate-it-until-it's-gone dept.

Security 183

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.

cancel ×

183 comments

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

One word (-1)

Anonymous Coward | more than 2 years ago | (#37297650)

Romanians

I'm sure they tried to connect to Undernet through the kernel.org servers

Or maybe (1)

unity100 (970058) | more than 2 years ago | (#37297666)

They didnt want to harm the kernel.

Re:Or maybe (2, Interesting)

Anonymous Coward | more than 2 years ago | (#37297738)

Or maybe, just maybe, the hackers wanted to appear that they didn't realize what they had gotten their hands on. I'm not trying to cause any tinfoil hats to come out, but I would still check everything.

Re:Or maybe (1)

Dwonis (52652) | more than 2 years ago | (#37299522)

Or maybe, just maybe, the hackers wanted to appear that they didn't realize what they had gotten their hands on. I'm not trying to cause any tinfoil hats to come out, but I would still check everything.

git fsck

Done.

The motive doesn't matter. It's time for action. (-1)

Anonymous Coward | more than 2 years ago | (#37297838)

Given their relative importance, the publicly-facing kernel.org servers should now be moved to OpenBSD. Although it may not be perfectly secure (no system ever is), it is by far the most secure open source operating system that exists today. It's one of the few open source software projects with a serious emphasis on doing things properly, and a major part of that philosophy revolves around proper code audits and security practices.

By moving the kernel.org servers to OpenBSD, the Linux community leadership would show that they take this matter very seriously. They would show a level of responsibility that we often don't see after incidents like this. Admitting to the attack in the first place is a good first step, but preventing future incidents is important, too. The use of OpenBSD would be a logical, if not necessary, next step in this direction.

Re:The motive doesn't matter. It's time for action (3, Insightful)

LordLimecat (1103839) | more than 2 years ago | (#37298058)

Question, how would OpenBSD prevent them from getting into the server with compromised username and password? Or from running arbitrary code once they do so?

Re:The motive doesn't matter. It's time for action (-1, Troll)

Anonymous Coward | more than 2 years ago | (#37298412)

Even the most inexperienced OpenBSD admins would know better than to use password-based authentication, and would instead choose one of the other, more secure, approaches. They'd also know how to set up their system such that a compromised user account could not cause widespread damage to the entire system. Furthermore, they'd know how to prevent privilege escalation. They'd also have much better intrusion prevention and detection measures in place.

I hate to admit it, but many of these basic concepts are far beyond even the best Linux admins.

Re:The motive doesn't matter. It's time for action (3, Insightful)

LordLimecat (1103839) | more than 2 years ago | (#37298490)

Yes, well everyone knows those kernel.org sysops are a bunch of pushover newbies. Im sure you can do way better with the scope and size of the systems they deal with.

Re:The motive doesn't matter. It's time for action (0, Interesting)

Anonymous Coward | more than 2 years ago | (#37298658)

You should read this article:
http://www.h-online.com/open/news/item/Kernel-org-gets-major-system-upgrades-1142346.html [h-online.com]

If that description from late 2010 (less than a year ago!) is still accurate, there is almost no infrastructure at all. In case you refuse to read it for yourself, let me quote to you from it:

In total the kernel.org infrastructure uses 12 servers worldwide.

Unless you're a high school kid who has only ever managed a VPS instance running Linux for some shitty Ruby on Rails site, a mere 12 servers should seem like absolutely nothing to you. Most professional sysadmins will manage hundreds to even thousands of times that number of servers.

Re:The motive doesn't matter. It's time for action (5, Funny)

Slashdot Assistant (2336034) | more than 2 years ago | (#37298580)

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.

Re:The motive doesn't matter. It's time for action (1)

Anonymous Coward | more than 2 years ago | (#37298918)

Is this a joke or are you completely clueless?

Re:The motive doesn't matter. It's time for action (1, Informative)

RobbieThe1st (1977364) | more than 2 years ago | (#37299034)

He's being funny, in case you can't tell.

Re:The motive doesn't matter. It's time for action (1, Funny)

gnapster (1401889) | more than 2 years ago | (#37299494)

This is why I never comment until the mods have had a chance to let me know whether I should be laughing.

Re:The motive doesn't matter. It's time for action (2)

rubycodez (864176) | more than 2 years ago | (#37299444)

I'm curious, once inside an OpenBSD server as normal user, what rootkit would they use instead of Phalanx to elevate privileges? The OpenBSD teams has expended a lot of effort to combat such a thing.

Re:The motive doesn't matter. It's time for action (0)

diego.viola (1104521) | more than 2 years ago | (#37298650)

Don't move to OpenBSD, improve Linux security instead.

Re:Or maybe (0)

Anonymous Coward | more than 2 years ago | (#37298316)

More likely they moved on because they found that there was no money to steal from kernel.org, and no secrets worth selling.

and after reading the articles.... (1)

poofmeisterp (650750) | more than 2 years ago | (#37297672)

...and didn't realize the value of the servers that they had gotten their hands on...

....I don't see any mention of what the phrase refers to. Is this dramatization or intentionally excluded information?

Curious.

Re:and after reading the articles.... (5, Informative)

Samantha Wright (1324923) | more than 2 years ago | (#37297690)

Here [bell-labs.com] is what it's referring to. CS graduates are expected to recognize instances of it instinctively.

Re:and after reading the articles.... (1)

poofmeisterp (650750) | more than 2 years ago | (#37297756)

Here [bell-labs.com] is what it's referring to. CS graduates are expected to recognize instances of it instinctively.

Ah, so the statement was conceptual, not based on a hidden component within these boxes. Gotcha.

Correct me if I'm wrong.

Re:and after reading the articles.... (5, Insightful)

Samantha Wright (1324923) | more than 2 years ago | (#37297850)

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.

Re:and after reading the articles.... (1)

KahabutDieDrake (1515139) | more than 2 years ago | (#37298326)

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?

Re:and after reading the articles.... (0)

Rockoon (1252108) | more than 2 years ago | (#37298372)

Isn't it just a matter of examining the Kernel code until you find the naughty bits and expunge them?

Thats right. A task that can never be proven to be completed.

Re:and after reading the articles.... (4, Informative)

jimicus (737525) | more than 2 years ago | (#37298428)

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.

Re:and after reading the articles.... (2)

Samantha Wright (1324923) | more than 2 years ago | (#37298524)

That's exactly the idea. While such a move would eventually be discovered, the amount of damage that could be done before that happened could be substantial, and the amount of work required to (a) find the bad code in a copy of the source tree and, especially, then (b) detect bad binaries would be pretty staggering. It should also be stressed that this isn't just some fanciful nightmare scenario as Kahabut suspects; Ken Thompson did it to the Unix kernel long ago.

Re:and after reading the articles.... (0)

Anonymous Coward | more than 2 years ago | (#37299292)

This requires compilation on a system, though - and (at least the way KT did it) requires a malicious compiler which spots it is compiling itself and adds in the malicious code or spots it is compiling the kernel and adds in code to include a backdoor.

How would a malicious kernel achieve the same thing? It would need to include a backdoor, also code to spot that it was being recompiled and amend the output of the compiler to perpetuate the backdoor. Seeing as kernel.org just provides code, which has to be compiled and run at least once, that's a pretty huge amount of malicious code to hide in a commit.

So a malicious commit could probably have been inserted, but I bet the kernel hackers are all busy checking for any fishy commits, and once the malicious commit is found it could be diked out. The nightmare scenario would be someone inserting malicious code into the gcc git tree and having it compiled and therefore self-perpetuating. But it would be spectacularly poor IT management if anyone doing anything remotely important was using the gcc git tree to compile anything except test cases - certainly not a production gcc!

Re:and after reading the articles.... (0)

Anonymous Coward | more than 2 years ago | (#37298556)

You should read "Ken Thompson's Reflections on Trusting Trust"
Or at least the wikipedia article about backdoors [wikipedia.org] .
You can not trust source code unless you know that the binaries on your system are clean.
Even if you decide to check the resulting binary with a hex editor you can not be sure since you don't know if you can trust your hex editor.

Re:and after reading the articles.... (1)

del_diablo (1747634) | more than 2 years ago | (#37298802)

Or we take advantage of how git works, and axe all those commints that is noncomplient against history.

Re:and after reading the articles.... (1)

sjames (1099) | more than 2 years ago | (#37299436)

Except for those bazillions of good systems burned onto CDROMS already, any one of which could be used to bootstrap.

It would take a lot more than one generation of corruption to overcome that.

How could the attackers... (2)

Nutria (679911) | more than 2 years ago | (#37297678)

not know what they had cracked and how useful it was?

Re:How could the attackers... (1)

FooBarWidget (556006) | more than 2 years ago | (#37297720)

Maybe a semi-automated attack in search of more zombie machines for sending spam.

Re:How could the attackers... (2, Informative)

Anonymous Coward | more than 2 years ago | (#37297814)

Any random machine with SSH enabled gets around 2-3 brute force attempts per day from automated zombies. Most likely kernel.org was breached in an automated attack. I've protected my server with Denyhosts which will add your IP address to the firewall after 5 failed passwords... indefinitely. kernel.org should either install it or switch to public key authentication. Having user/password authentication on Internet without any protection is real stupid.

Re:How could the attackers... (4, Informative)

Dahamma (304068) | more than 2 years ago | (#37297940)

2-3? Mine sometimes gets hundreds. It's pretty ridiculous.these days.

Re:How could the attackers... (1)

cdoggyd (1118901) | more than 2 years ago | (#37297758)

Happens all the time. I've seen servers compromised with no attempt to harvest email addresses, ecommerce data, or passwords. Most of these "hackers" are script kiddies that use automated tools to locate and compromise servers. Once they're in, they don't really know what to do next to take full advantage of their access. Hooray for amateurs.

Re:How could the attackers... (2)

beuges (613130) | more than 2 years ago | (#37298588)

This argument doesn't make sense. From what I've read, a kernel dev with kernel.org access had his machine trojanned, and the attackers got to kernel.org in that way. That's a far cry from script kiddies trying SSH ports on a bunch of random IP addresses. It sounds like quite a lot of effort to specifically get to the kernel.org network. Whether they managed to do some unknown damage, or access some other data whose relevance is as yet unknown, or maybe they just did it for the reputation of having hacked kernel.org doesn't matter - it does seem to be a targetted attack and the attackers would definitely have known what they had.

These types of stories are actually more harmful than anything else - instead of calming people down by downplaying the severity of the incident, they're creating the impression that kernel.org was taken down by a bunch of script kiddies doing random port-scans and dictionary attacks, which in turn makes the kernel.org admins look pretty foolish. Not good PR at all.

Re:How could the attackers... (1)

LordThyGod (1465887) | more than 2 years ago | (#37299076)

Trojanned? By what, do we know? I hope the dumb fuck wasn't running windows.

Wishful thinking? (0, Interesting)

Anonymous Coward | more than 2 years ago | (#37297686)

My philosophy has always been: once a machine has been compromised, all bets are off. Let's say you're paranoid enough: couldn't you just as easily argue that the "mistakes" that have been detected are simply misdirection, drawing attention away from the real hack (eg. backdoor inserted in the kernel)? How sure can you really be that the kernel source integrity is intact?

Re:Wishful thinking? (4, Informative)

MimeticLie (1866406) | more than 2 years ago | (#37297802)

Did you bother to read either of the two [linux-foundation.org] links [blogspot.com] 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.

Re:Wishful thinking? (1)

Crazy_entertainer (2442572) | more than 2 years ago | (#37297852)

A clever rootkit could hide that. Of course the rootkit would have to target Git with a fake version. With source code available it can be done.

Re:Wishful thinking? (1)

Runaway1956 (1322357) | more than 2 years ago | (#37297936)

So - Billy Random Hacker aka Snotnose Scriptkiddie just happens to have authorization via git to change the source code? Then - why didn't he come in through the front door, and change the source code? It makes no sense, I tell you! It's like, I have a safe deposit box at my local bank, and I want to change the contents of that box, so I break in at night to do so. When, all along, all I needed to do, was to walk in during business hours, and inform any bank officer that I need access to my box.

What am I missing here, that seems so obvious to you and so many others?

Re:Wishful thinking? (1)

HJED (1304957) | more than 2 years ago | (#37299400)

Git records when changes are made (it has to to work and by whom it would be very easy to detect and edit if they changed it through the metaphorical front door and could be changed back. What is being suggested is that someone hid the changes (which would require manual access to the git files).

My understanding is this would not be too hard, but apparently it is?

Re:Wishful thinking? (1)

Superken7 (893292) | more than 2 years ago | (#37297904)

While the distributed nature of git sure makes it difficult for the kernel source to be compromised, I think that's a bit optimistic (I confess I only read one of those two links, though).

It looks like they argue that since every commit is hashed and everyone has got a full copy, it would be really difficult for someone to alter any single byte without raising suspicion. However, it should be noted that one or several developer accounts got compromised (which later resulted in privilege escalation to root).
How do you know they did not commit something to a developer's tree, then push it upstream? That is, since they got at least one of the developers (if not many, which could complicate things further by "distributing" the harmful change over several different commits from different people) how do you know its not a *legit* commit?

The developer who got himself (or at least his passwords) compromised would need to find out that one of his commits isn't really made by him. That could be not easy to spot, especially for others if the exploit is well hidden. (off-by one bugs that result in remote exploitation come to mind - not trivial but certainly possible and difficult to detect when writing C code)

Of course, code by those developers could be audited, but I that is far from saying: "bah, we got compromised but we sure as hell know the source isn't compromised", which is how it sounds to me.

Re:Wishful thinking? (1)

MimeticLie (1866406) | more than 2 years ago | (#37297984)

(I confess I only read one of those two links, though)

Did you read the second one? Because it deals with the specific situation you mention, with a hypothetical about Linus' account getting compromised. I'm not an expert on Git, but according to the article, the developer in question would be informed by Git that a commit had been made that didn't match their personal repository the next time they tried to submit their changes.

Re:Wishful thinking? (2)

Superken7 (893292) | more than 2 years ago | (#37298174)

The second link deals with kernel.org being compromised, I am talking more about a legit commit making its way to the kernel tree. i.e. What happens if Linus Torvalds get compromised and someone uses *his* repository to add malicious stuff, which will eventually get pushed upstream?

That is, what's preventing a legitimate and trusted developer from introducing malicious code? That could happen as soon as a developer is compromised, which if I'm not mistaken is exactly what happened and how kernel.org got compromised (which in turn might have exposed credentials from more devs)

Re:Wishful thinking? (1)

Riceballsan (816702) | more than 2 years ago | (#37297826)

Well you could start by thousands of tin foil hats who are most likely looking at and scrutinizing every line of the code. Though wouldn't it be safe to assume there are backup copies off of the server? Isn't it possible they just either did an md5sum comparison or loaded the backups over the online versions to be safe.

Nonsense! (5, Funny)

Anonymous Coward | more than 2 years ago | (#37297694)

They must have gotten their hands on the kernel source code, I found it posted online!

sure THESE guys didn't touch the kernel... (1)

Anonymous Coward | more than 2 years ago | (#37297698)

but how do we know someone more sophisticated didn't already break in and mess with the code undetected?

Re:sure THESE guys didn't touch the kernel... (1)

migla (1099771) | more than 2 years ago | (#37297742)

>but how do we know someone more sophisticated didn't already break in and mess with the code undetected?

Lots of people probably have the same git source repo on their own computers, so it can be compared to the kernel.org one.

Re:sure THESE guys didn't touch the kernel... (0)

Anonymous Coward | more than 2 years ago | (#37297794)

Can? Does that happen?

Also, if people also automatically grab the newest tree, how do they know what changed where without looking at the changes?

Re:sure THESE guys didn't touch the kernel... (3, Informative)

Anonymous Coward | more than 2 years ago | (#37297806)

Because in git, everything has got a hash checksum that is not forgeable (try to get something that compiles, does specifically something malicious, and that has the same checksum and size as before).

And then there are thousands of copies of the entire thing around. I also have one. A simple comparison for equality will work.

Re:sure THESE guys didn't touch the kernel... (3, Informative)

John Hasler (414242) | more than 2 years ago | (#37298758)

Because in git, everything has got a hash checksum that is not forgeable...

And every commit is signed. When the Debian kernel maintainers fetch a new kernel (from Git, not a tarball) they verify the signature on every new commit. The integrity of the Linux kernel does not depend on anything as brittle as a sacred master copy.

Re:sure THESE guys didn't touch the kernel... (0)

Anonymous Coward | more than 2 years ago | (#37297858)

Yes, I know we are on slashdot, but have you tried reading the article? It is quite clearly explained how they know that in the second link.

To summarize:
1. Git checksums each file and each commit using SHA-1. Thus, you can not modify files directly without being noticed.
2. Each kernel developer with permission to publish to kernel.org works with a single-guy public repository inside kernel.org
3. Any commit injected directly to their public repositories would be detected the next time that they wanted to push to their repos (big warning sign saying that they will *lose* one commit, when this is *never* supposed to happen to them).
4. The "3" sign has not happened to anybody.
5. Therefore, no code messing.

Comon .... (0)

Anonymous Coward | more than 2 years ago | (#37297702)

So with some "random" automated exploit/credentials some random "script kid" owned kernel.org?

Comon Oberheide , they probably used one of your exploit on top of that?

Busticati .....really.....

this just sounds stupid. (0)

Anonymous Coward | more than 2 years ago | (#37297744)

if someone wanted to, and were able to, compromise the kernel.org servers.. and they were 'good' do you not think they would be able to make people think it was just script kids? and that they didnt know what they had? it sounds unreasonable to me. you would *think* kernel.org servers would be somewhat secure. you would *hope* they are somewhat secure. is it possible they wanted their crap rootkit to be found to disguise what really occurred? it all sounds pretty shady to me. but what do i know.

Idiots (0, Flamebait)

Anonymous Coward | more than 2 years ago | (#37297750)

Not the attackers, the people who believe someone hacks a server like that and doesn't know what it is. To me this story means that the people who are responsible for the security of the Linux kernel are easily distracted by planted evidence, which prevents a thorough investigation. If they keep using that machine, the integrity of the Linux kernel is going to be questionable.

Why? (1)

MattGWU (86623) | more than 2 years ago | (#37297760)

Why would the attacks have to look different? Because if somebody wanted to mess with the source, they'd be more sophisticated and use more sophisticated exploits? Like Kaspersky pointed out, if they wanted to mess with the source code, a lot of what they did would have been unnecessary, but whatever initial exploit they used would have still worked! I think the real point is here 'they got in'. Better attackers just mean they wouldn't have discovered the break-in as quickly, and actual damage might have been done. Whether or not the attackers knew what they had is immaterial: the real message here is kernel.org needs to wake up and get serious about security, if any random script kiddie can root them.

Patching (0)

Anonymous Coward | more than 2 years ago | (#37297776)

Does think mean kernel.org is not patched on time or there are simply too many vulnerabilities in Linux to keep up? How did the attackers get in? Brute Force? Exploiting some known/unknown vulnerability or reused ssh keys? Social Engineering?

Obviously (-1)

Anonymous Coward | more than 2 years ago | (#37297818)

If a Windows server is hacked, Windows sucks. If a Linux server is hacked, hackers had luck.

Re:Obviously (2)

Larryish (1215510) | more than 2 years ago | (#37298806)

If a Windows server is hacked, hackers had luck.

They were lucky it wasn't Linux.

The truth (1, Insightful)

Iskorptix (2452916) | more than 2 years ago | (#37297828)

I think the truth is that failers trying to save their asses and trying to make themselves heroes here.

Re:The truth (1)

xushi (740195) | more than 2 years ago | (#37297856)

Failures.

FAIL!

Spin (4, Insightful)

93 Escort Wagon (326346) | more than 2 years ago | (#37297840)

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.

Re:Spin (4, Insightful)

microbee (682094) | more than 2 years ago | (#37297996)

Yeah, just admit failure and do better next time. No need to blog about how a trivial issue it was.

Re:Spin (4, Interesting)

Rogerborg (306625) | more than 2 years ago | (#37298048)

We totally hadn't detected any intrusion!

Uh... then we did.

But we totally haven't detect any meddling with the sources

Uh...

I think most likely... (1)

icongorilla (2452494) | more than 2 years ago | (#37297842)

It wasn't until they got into the machines that they realized the Kernel wasn't written in Javascript. "Dammit!"

I'd Still Like To Know... (1)

mgmartin (580921) | more than 2 years ago | (#37297866)

How they got root access after logging in. Was it something simple like a sudo? Was it a known, unpatched kernel vulnerability? Or, was it some new vulnerability current kernels are susceptible to? Last I read, they logged in under a user account, then they got root access.

Re:I'd Still Like To Know... (0)

Anonymous Coward | more than 2 years ago | (#37298400)

Why is it so surprising? Sounds like the most mundane thing if you pay attention to security mailing lists. (Hint: You wont see linux security bugs hitting the frontpage on slashdot for obvious reasons) Linux has had dozens of privilege escalation vulnerabilities, more so than NT. (Although on windows.. most of the idiots run as admin.. so it isn't required anyway)

http://www.exploit-db.com/platform/?p=linux [exploit-db.com]

Re:I'd Still Like To Know... (1)

rubycodez (864176) | more than 2 years ago | (#37299488)

some other open source OS put in huge amount of time with the goal of making that impossible, the standard is zero *known* privilege escalation and they will ASAP fix any found. the Linux devs should adopt a similar attitude.

Re:I'd Still Like To Know... (4, Informative)

beuges (613130) | more than 2 years ago | (#37298434)

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.

Re:I'd Still Like To Know... (1)

inode_buddha (576844) | more than 2 years ago | (#37299526)

Good points, all. I've been saying this for a while now. You know what's even sadder? The fact that so many commenters can't be arsed to RTFA let alone the links. And even if they do read, the comprehension seems to be lacking. This is why your post is so necessary and good.

Feeling better (5, Insightful)

ChatHuant (801522) | more than 2 years ago | (#37297878)

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.

Re:Feeling better (1)

St.Creed (853824) | more than 2 years ago | (#37298026)

Lol... bonus points for excellent use of sarcasm :)

Re:Feeling better (1)

drolli (522659) | more than 2 years ago | (#37298750)

And right now, somewhere... somebody of the highly knowledgeable penetration team says something like "phew i thought these stupid punks get us caught".

Hmmm (0)

Anonymous Coward | more than 2 years ago | (#37297884)

If they were looking for something to steal, it would be easier to wait until the next release.

The fact that the servers were hacked (-1)

Anonymous Coward | more than 2 years ago | (#37297910)

The fact that the servers were compromised in the the first place brings to question the ability of the administrators to lock down a system.

Re:The fact that the servers were hacked (1)

Superken7 (893292) | more than 2 years ago | (#37297966)

Another way to look at it: the fact that the administrators found out and admitted getting hacked says a lot about the ability of the administrators.

I would rather trust these guys than someone who claims to have never been hacked ever.
Its not like they get hacked all that often, which sure would make them look bad.

Re:The fact that the servers were hacked (0)

Anonymous Coward | more than 2 years ago | (#37298122)

Certainly I agree. Although any modern IDS like Samhain or tripwire would have picked up this attack within one day of occurring and even told you which files were changed. In conjunction with something like Splunk would have provided very robust security auditing tools. In consideration of all these tools that are available, I can not help but to think that this compromise should have never of happened or at least taken 17 days to recognize. Even tools like selinux or apparmor can be very effective at thwarting these attacks. Or how about rate limiting ssh to block brute force ssh attacks...as this was most likely the egress point for this particular compromise.

I hope these system administrators are reading this because they really need to get a clue.....and to intentionally add insult to injury, evaluate their security best practices.

 

Re:The fact that the servers were hacked (1)

inode_buddha (576844) | more than 2 years ago | (#37299356)

It wasn't brute-forced. A user with commit privs had his work laptop trojanned. Yes, I actually was reading kernel.orgs emails when it happened. and all these other articles.

Re:The fact that the servers were hacked (1)

baegucb (18706) | more than 2 years ago | (#37299420)

They need to get their MCSE certification updated ;)

Two ways to look at this... (4, Insightful)

CajunArson (465943) | more than 2 years ago | (#37297924)

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.

BUT CHA JUST DON'T KNOW, DO YA !! (0)

Anonymous Coward | more than 2 years ago | (#37297952)

maybe they didn't, but maybe they did !! All Your Bases Are Belong To Us !!

hey there's this OS its supposed to be more secure (1)

lkcl (517947) | more than 2 years ago | (#37297958)

they should run linux on their servers, it's more secure! oh wait... whoops. ho hum, i suppose it's no good saying that they should run a FreeBSD Bastion Server, is it?

popularity (1)

sourcerror (1718066) | more than 2 years ago | (#37298138)

Now Linux is popular enough to have rootkits. This must be the year of Linux on the desktop.

Re:hey there's this OS its supposed to be more sec (1)

dririan (1131339) | more than 2 years ago | (#37298410)

If you have weak passwords, no OS is going to help you. The only thing that helps you there is something like DenyHosts or fail2ban. Not even OpenBSD prevents stupid.

Re:hey there's this OS its supposed to be more sec (1)

rubycodez (864176) | more than 2 years ago | (#37299506)

but how about that "privilege escalation' business that Linux couldn't prevent?

They should have been running Windows Server! (1)

blahbooboo (839709) | more than 2 years ago | (#37297990)

This wouldn't have happened if they ran closed source Microsoft Windows Server :)

It's a joke guys kidding :P

Re:They should have been running Windows Server! (1)

Beelzebud (1361137) | more than 2 years ago | (#37298852)

Somebody mod this guy Heretic!

But did they find.. (1)

Fuzzums (250400) | more than 2 years ago | (#37298068)

So they found the SSH Frontdoors, but did the admins find the rest?

Re:But did they find.. (1)

Anonymous Coward | more than 2 years ago | (#37298506)

Weather or not they found them they are gone. Nuke & reinstall. Nobody running those servers would do anything less, except perhaps restore from backup using trusted media, which is also good.

Kernel.org may not bother with clean wipe (2)

mindbuilder (960119) | more than 2 years ago | (#37299044)

Disturbingly they seem to have considered not wiping and reinstalling.

System is being verified from backups, signatures, etc. As of right
now things look correct, however we MAY take the system down soon to do
a full reinstall and for more invasive checking.

(emphasis added) John 'Warthog9' Hawley
Chief Kernel.org Administrator http://pastebin.com/BKcmMd47 [pastebin.com]

It appears that the chief kernel.org system administrator is so naive about security that he doesn't even realize the absolute necessity of a full wipe and reinstall after compromise of such an important site. It also appears that there was no routine booting from read only media to check system files and startup scripts for changes. And no daily rootkit scan. If it was me, I would trash the motherboard for fear of BIOS or other firmware contamination. Exploits living on the firmware of network cards and other places have been demonstrated.

Re:Kernel.org may not bother with clean wipe (1)

aegl (1041528) | more than 2 years ago | (#37299440)

Perhaps considered - but rejected. www.kernel.org now says:

"We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls."

Details (0)

Anonymous Coward | more than 2 years ago | (#37298190)

Any details on the hack? What port did they use, for example? What service was compromised first?

Whew (0)

Anonymous Coward | more than 2 years ago | (#37298228)

And most importantly, they didn't find out the Kernel's secret 11 herbs and spices.

old story. (1)

arunce (1934350) | more than 2 years ago | (#37298250)

Or so they think.

saving face (0)

Anonymous Coward | more than 2 years ago | (#37298422)

after decades of bashing microsoft security, this story only exists to save face

tripwires (0)

Anonymous Coward | more than 2 years ago | (#37298488)

so the live servers didn't have something running that checked the hash of the sources every, lets say, a day? why the hell not?

Or maybe... (1)

mmcuh (1088773) | more than 2 years ago | (#37298600)

...they were just script kiddies who knew one single method, and thought it would be cool to try it on kernel.org.

DVD backups MUST be made and distributed periodica (0)

Anonymous Coward | more than 2 years ago | (#37298612)

We need the copies of the source code to be on multiple/hundreds Write Once DVD media. Fact is even if you have a billion computers if they are all vulnerable to the same exploit or _an_ exploit .. it can be compromised in an automated fashion. The source needs to be periodically placed on DVDs.

Which is exactly what I would say... (2)

rocket rancher (447670) | more than 2 years ago | (#37298618)

...if I was in charge of damage control at kernel.org. Just sayin'.

Main website tarball (2)

David89 (2022710) | more than 2 years ago | (#37299432)

I still haven't managed to figure out if the tarball you download from the main page has been compromised.. Yes GIT saved everybody and all, but they seem to not want to say anything about the front page tarball, makes me curious
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

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>