Linux Kernel Back-Door Hack Attempt Discovered

An anonymous reader writes "The BitKeeper to CVS gateway was apparently hacked in an attempt to add a root exploit back door to the Linux kernel, according to the linux-kernel archive. The change was in the file kernel/exit.c and changed the user ID of a process to root under the guise of checking the validity of some flags. The core Linux BitKeeper kernel repository was not at risk, and in fact it was the BitKeeper CVS export scripts that detected the unauthorized modifications to CVS. The changes were falsely attributed in CVS to long-time Linux developer davem (David Miller). Users of the BKCVS repository should resync their trees to remove the offending code if they had replicated it since yesterday."

Re:Well well

[chill]

Good to see the system works. You would wonder what would happen if said hacker was working for a company on a similar closed source program. Would it have been detected?

You mean like Borland's Interbase? The compiled in backdoor [cert.org] wasn't discovered until after the database opensourced.

My favorite quote from the advisory is:

"This vulnerability was not introduced by unauthorized modifications to the original vendor's source. It was introduced by maintainers of the code within Borland. The back door account password cannot be changed using normal operational commands, nor can the account be deleted from existing vulnerable servers [see References]."

How long was it in there? "These security holes affect all version of InterBase shipped since 1994, on all platforms."

The advisory dates from 2001 -- you do the math.

Curious abot the hack, was it remote?

[nereid666]

i want to know if the hack was a remote backdoor or "only" a local root compromise. In order to how bad was the hacker that try to do this.
Thanks to the admins and developers that detect that!

Re:Microsoft

[MrLint]

My guess is more likely DDoS and spam hackers. Looking for ways to get in and grab more things to attack with.

The more eyes...

[Sean Clifford]

> Setting current->uid to zero when options __WCLONE and __WALL are set? The
> retval is dead code because of the next line, but it looks like an attempt
> to backdoor the kernel, does it not?

It sure does. Note "current->uid = 0", not "current->uid == 0". Good eyes, I missed that. This function is sys_wait4() so by passing in __WCLONE|__WALL you are root. How nice.

And this is exactly why folks should insist on open source code.

Assuming it was noticed, and I have little reason to think that modification of a project's cvs tree would go unnoticed, a closed source product would have to go up and down the development chain of command. Then likely up and down the marketing chain of command while a decision was made whether to say anything about it (yeah, right) was made. Meetings would be held, blame would be assigned, and - oh yeah - a discussion about a fix would ensue.

Perhaps I exaggerate, but only a little.

I remember when a beta of a game [unnamed software publisher] was working on got ripped off our company ftp site and passed around. There was so much hype about our game that the leaked late beta was a serious disappointment and effectively killed the good buzz the marketing folks had whipped up. [It blew anyway, got shredded by the gaming rags, had a lot of potential but an inexperienced crew and very little financial support.]

Of course, this situation is nothing like that.

There's always going to be someone trying to backdoor the linux kernel, windows, osx, apps galore. Having the source on-hand to look at gives you that added level of confidence that "hey, worst case we can fix it - deal with it ourselves" rather than go through the denial, silence, lame excuse, patch cycle you go through with closed source products.

Ebay-style attacks

[blastedtokyo]

While this attempt was thwarted, it makes you wonder though if someone could do an Ebay style 'attack.'

In other words: 1) Work on the code for a long time, developing good features and build up virtual reputation points so that people trust you. 2) One day decide to insert your backdoor amidst some big checkin. 3) Disappear.

It doesn't seem hard for someone to pay some random third world programmer to do this so. For example, if Red Hat had a guy in russia doing this they could, after the latest kernel was widely distributed, use it to attack Novell/SUSE.

Re:Well well

[Narphorium]

Although I see where you're going with this, I think a lot of people might ask whether this shows vulnerability in OSS instead. Sure, you and I appreciate this as a validation of the system but is that really how the media is going to portray it?

All I'm saying is that I certainly won't be surprised when closed source vendors start using this in their anti-OSS campaigns.

Re:Well well

[Geek of Tech]

> Why is this relevant? The fact that anybody that HAD seen the source code to Interbase could exploit it was enough. This could include ex-employees and contractors. Would you be happy with Microsoft including a back-door to all their software as long as only they knew how to exploit it?

What?! They don't already? Oh I forgot the Backdoor, uh, I mean DRM isn't due in Windows until Longhorn...

Re:Well well

[blair1q]

It was only detected because software found a discrepancy.

This would happen at any closed-source shop that had the same software.

No human eyes discovered the problem, and if someone hadn't installed the checks, it might not have been discovered for months or years or ever.

Unfortunately this wasn't an accident.

[Ungrounded Lightning]

In my code I always put the constant on the lhs so that the difference between the equality (==) and assignment (=) operator are caught by the compiler by accident.

Good style.

But this was apparently not an accident, but a deliberate attempt to disguise a trapdoor. As such the author would, of course, just "forget" to use that piece of defensive programming. B-)

*sigh*

[inode_buddha]

On a slightly related note, I'm reminded of Bob Toxen's anecdote from his grey-hat days when he hacked the US Navy, or some such. Did it by way of a backdoor in the compiler IIRC. Can't be bothered to dig out the book at the moment, but you might want to get a copy of the 1st edition and check out his site at realworldlinuxsecurity.com [realworldl...curity.com].

I see a lesson in this: The oldest tricks are probably the best, or else they wouldn't live long enough to be "old".

I'm a LKML subscriber, so yeah I'll say this: Larry McVoy's gonna be pissed, and $DEITY help whoever...

If you think the flamewars and trolling is nasty here, you should see them over there, trust me on that.

Re:Yet another reason to use open source software

[Florian Weimer]

Had this code come in through proper channels, I wouldn't be so sure that it would've been spotted.

I doubt it, too. For example, in 1998, the CORE SDI put a backdoor into most SSH 1 implementations, which was included in their CRC32 attack decompensator. Of course, they didn't do it on purpose, but it happened nevertheless, and peer review didn't catch it.

Re:Trusting Trust

[cperciva]

In the end, some naferious super genious at Intel, or Western Digital could generate an evil piece of hardware specifically designed to subvert gcc and linux at the hardware level. Granted it be nearly impossible to pull off...

Actually, it wouldn't be hard at all. Add logic into the L1 (data) cache which computes the MD5 sum of each cache line loaded; if it is equal to a predetermined value, the address of that line is loaded into the instruction pointer.

Presto, immediate backdoor which can be exploited by anyone who can load arbitrary data into address space (anywhere) and access it. The most obvious approach would be to send an IP packet with the exploit code -- the exploit would run as soon as the packet reached the IP stack -- but you could access it via a compiler as well.

Re:yet another reason for (CONSTANT == var)

[Anonymous Coward]

Yet another reason to have the root uid not be zero, more like. If the root uid was a value that was determined at system install time and had to be read off the harddisk at boot time, the code would be current->uid == root_uid and it'd stick out like a sore thumb.

In fact, why is the uid an int anyway? This is classic UNIX arse coding style. We have types, boys, we should use them for JUST this kind of error checking.

Re:Well well

[DunbarTheInept]

Kinda proves Steve Ballmer's comments about the lack of security in Open Source development, doesn't it?!

No. I just proves you're a posturing idiot. The crack was detected as soon as it was attempted to be inserted, in the experimental development version of the code that hadn't even made it into any final distributions yet.

And here's another example of your idiocy:

If it happened in a software company, the hacker would be fired and probably charged with some kind of "espionage" charge and arrested.


This wasn't an "inside" job. If this happened at a company, to fill the analogy, it would have been an external person, NOT someone they could fire.

Re:Well well

[rixstep]

You're never going to know anything w/o the code. So many examples, they're too numerous to mention. It's hushed because of the panic it can cause.

MS once had a summer programmer who put 'The tree of evil bears bitter fruit - now crashing your system disk' into Word. It got in all the European editions.

The NT team loved putting in the names of beers in a screen saver. They used 'I love NT' in about seven languages to kick it off. Gates supposedly heard about it and went through the roof. So they disguised it for the next release.

Putting a back door in is not more difficult. And it's almost impossible to detect - if you don't have the code, and sometimes even if you do.

IBM's mainframes have long had a humungoid string which bypasses all security.

And so forth.

Re:I wonder why not a remote root hack

[technos]

Who says this wasn't one part of a larger plan?

Slip in a priveledge escalation bug that's hard to catch. Wait a week or two for it to make its way into the main repository unnoticed, then go back and add a little bit of code to the networking stack or Apache, etc, that allows you to execute arbitrary code as the user running the service.

what is creepy is that the latter may have preceeded the former, and some remote execution exploit has gone unnoticed somewhere.

Re:Well well [Thompson: Reflections on Trust]

[muonzoo]

Of course, at some point, we do have to trust someone.
Ken Thompson [bell-labs.com] wrote an original speculative essay [acm.org] on this for CACM [acm.org] back in 1984 of all years.

It is really well worth the read. The short form is that there exists a way to subvert the compiler such that it is no longer trustable and it will build a back door into the OS forevermore. This paper is a must read.

Re:more reason to sign patches?

[Anonymous Coward]

"This is a passphrase that is long but easy to remember. I would just like to tell you, Mister Password Prompt, that nobody will guess this!"

Actually, these sort of pass phrases are considered weak. Think about it: to generate all such pass phrases, you only really need a dictionary with every word in the English language, which isn't really all that high, computationally speaking. The length of a sentence that you'd need to be as secure as something shorter but more cryptic would make using a sentence as a pass phrase useless. Basically, it comes down to the amount of entropy in the pass phrase, and English sentences don't have a lot. It's not as bad as, say, using a password, but it's still not good.