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

Comments

Well well

[toddhunter]

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?

Re:Well well

[Anonymous Coward]

Most likely it would have been detected. We just wouldn't have heard about it.

Most companies use pretty good CVS-like tools.

Re:Well well

[blastedtokyo]

Hmmm..but would they have even found the security hole if it hadn't been open sourced?

Re:Well well

[alannon]

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?

Re:Well well

[The Munger]

Good to see the system works.

And what if we just haven't discovered the code that got through yet...

You've got to ask - assume nothing.

+5, Tin-foil hat.

Re:Well well

[Geek of Tech]

Well, I guess that means all the closed source developers have the same problem. And I guess they probably don't know either.

Re:Well well

[danheskett]

Not only that, but imagine this. The hackers (in the real sense, not the TV-movie sense) who write the real low-level stuff that makes various OS's work - for example in Linux people like Alan Cox, Linus, RMS, ESR, davem, and the other regular kernel contributors submit a lot of code. Well, those people dont necessarily but a lot of code is in the kernel.

Can anyone tell me for 100% certain that between GCC, the kernel, and various compile chain tools there isn't a subtle backdoor that creates an overrun, or a weak key, or anything like that somewhere along the line? Maybe what looks like an innocent bug or flaw or even stylistic change in one source combines with a similiar item in another source to create an exploit or a weak scheme.

These people - real hackers - are so clever (I mean serously, writing and maintain an OS for fun puts these programmers in the top 1% of all advanced systems programmers) that what is to say that they couldn't dupe everyone even with the source available to all?

I can imagine a situation where a corrupted/corruptable individual works hard to gain legitimate comitt access to certian tools that are widespread. GCC, the kernel, a shell or two, OpenSSL. That person starts making small changes that when aggregated expose a large exploit but when examined piece-mail are completely benign, or even benficical.

Does anyone doubt that its technically possible? How could any automated system or person ever discover this? I am a fairly competent programmer in some areas and there have been numerous times that I've had to dissect large pieces of code painstakingly over the course of days or weeks to trace back a nasty bug. Can anyone say that its not possible that this is *already* happening in the OSS world today?

Re:Well well

[TiggsPanther]

Yeah. There's no way they'd want to show an open-source project finding and warning about a problem within 48 hours in a positive light.

They'd find their customers wanting timely patches and accountability.

Re:Well well

[ajs318]

Yeah, but anybody who feels the need to use stuff like this, probably updates often and checks stuff as a matter of course anyway, and possibly even sandboxes test kernels - so the damage is self-limiting. If you always want the sharpest blades, you have to understand you can cut yourself. Ordinary mortals mostly run stock kernels, from their distributor or kernel.org. Somehow, I can't see such an obvious exploit finding its way into a major distro.

And really, it's just more evidence that the Open Source model works. There is really nothing wrong with making a mistake, as long as you learn something from it and share what you learned with other people so they don't have to make the same mistake. Pretending you never make mistakes is another matter entirely .....

Re:Well well

[rodgerd]

As anoth poster has pointed, this is a well-known thought experiment, and what it boils down to is: at some point, you have to trust someone.

Have you audited your motherboard BIOS? What about your network card - how do you know it doesn't have an IP stack on the ROM that dials home and dumps your network activity to someone? Hubs? Switches? Routers?

Do you really know what lives in your hard drive controller?

Re:Well well

[Filik]

Actually, the mere fact that these people saw the need to insert a new backdoor is a good sign (though not proof) that there aren't any old ones (or that they weren't very talented).

Re:Well well

[Haeleth]

> And what if we just haven't discovered the code that got through yet...

1. We know that SCO have been looking very closely at the Linux source code.

2. We also know that none of the Linux boxes which serve major anti-SCO websites have been hacked into.

3. We can deduce therefore that SCO have not found any backdoors in the Linux source code.

While given their general level of (in)competence this doesn't amount to proof that there aren't any, it's probably a fairly safe bet.

Re:Well well

[blowdart]

RMS *must* be a low level hacker

No, he's a low level heckler ... "Shut up! It's GNU linux." "Shut up! It's GNU linux." (repeat ad nauseum)

Re:Well well

[Anonymous Coward]

Two Brazilian expressions, for your delight:

1) "Boi de piranha":

When you want to make a cattle herd cross a piranha-infested river, you probably will lose many cows (or oxen) -- the trick is get a first ox inside the river for sacrifice; while the piranhas devour it, the rest can pass unharmed.

2) "Porteira que passa um boi, passa uma boiada":

If a gate is wide enough for passing an ox, it's wide enough for an entire herd.

-//-

Have a nice day!

Re:Well well

[TrombaMarina]

My experience with proprietary software development is that in the beginning, there is a deadline. Then requirements get added to that deadline and code gets written until the deadline is reached. At which point the code is either shipped as is or the deadline is extended and the cycle begins again.

Show me a company that has the money to pay for developers to sit around and double-check every commit to a source tree. Show me a code review at a company where anyone besides the author has read the code before the meeting. Then I'll believe that THAT company COULD detect a hack like this.

Open source is not perfect, there's probably exploits in the kernel, intentional or otherwise, that have never been found and there always will be. But compared to deadline-driven "not-my-department" development, it's pretty darn impressive. Heck, I'm impressed that anyone ever discovered this.

P.S. Pay attention to the fellow who suggested (in another post) that we check other software for a companion hack for this exploit. Someone clever enough for this back-door undoubtedly has another somewhere to set those flags remotely. Maybe in the next version of CVS or another tool he used to insert the hack that was found.

Yet another reason to use open source software

[Mipsalawishus]

This is the reason I trust open source software. The power of peer review (in one form or another) catches these kinds of things before they are sent into the wild.

Re:Yet another reason to use open source software

[mcroot]

Peer review did not catch this. This was detected because people injected code into a specific place where inconsistencies are complained about by the revision control software.

Had this code come in through proper channels, I wouldn't be so sure that it would've been spotted. Most of the source code trojans people have found in the past were not well hidden, and were turned up relatively shortly. The cases I'm referring to are the trojaned configure scripts, that happened to, I believe, irssi and dsniff, or was it fragroute.. (it was definitely something by Dug Song)

If you would like to tout peer review. Could you provide a valid example ? They probably are out there, but I can't recall any, and this is not what happened here.

more reason to sign patches?

[tomstdenis]

Why not just establish a web-o-trust and sign patches?

That way people who hack in won't be able to send in signed patches to the system [e.g. even if they physicially update the tree others can trivially spot the unsigned patches].

That would of course, require people to actually think about security in terms of "oh sure people won't hack it because it hasn't been done...much...before."

Tom

Re:more reason to sign patches?

[Anonymous Coward]

this wouldn't solve much.. now the barrier for adding a backdoor would be hacking a contributor's computer.

Re:more reason to sign patches?

[Tailhook]

How would a web of trust help? Odds are the backdoor was introduced by compromising some developers machine. If that is the case then whatever cert would be needed to sign a patch would probably also be compromised.

All signatures would do is raise the bar a tiny bit and provide a false sense of security. Whoever pulled this off wouldn't be hindered in the least if the bar had been a little higher. At best you would be able to point a finger at the developer responsible for the cert, but why would the perpetrator care about that?

There is no magic bullet for this kind of thing. It's Open Source and the operative word is "open." Only because it's open was this caught. Closed source is even worse.

Re:more reason to sign patches?

[jrockway]

Yeah it's really easy to sign code when you don't have the key. All you have to do is try about 2^1024 different combinations of 1's and 0's. Simple, but not if you want it done before the Universe is gone.

And if you have access to the key, remember that it's encrypted with a passphrase. Assuming it's 40 letters or longer (Something like "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!"), you would have to try about 100^40 different passphrases. That's hard.

So basically, it's really hard to forge a digital signature. Harder than breaking into the BK server, anyway.

Re:more reason to sign patches?

[Tailhook]

Yeah it's really easy to sign code when you don't have the key.

If a developers machine is compromised (as I imagined in my post) getting the passphrase is trivial. How many different ways can you imagine discovering the keyring passphrase on a machine you have the ability to discretely administer?

Just off the top of my head (and no astronomical exponents required):
Man-in-the-middle the keyring editor
Scarf it from memory
Monitor keystrokes

Harder than breaking into the BK server, anyway.

No one broke into a BK server. The BK content is routinely exported to a CVS server so that free software zealots have something to pull from that doesn't involve using BK. The backdoor was done directly on that CVS export (probably by compromising CVS pserver) in the hope that someone who actually uses the CVS server would pick it up and submit the altered file as a patch into the BK tree. Several more things would have had to occur for the backdoor to have "worked": some developer would have had to pick up the altered file, submit that file to Linus, have Linus (and ultimately everyone else) miss the backdoor and commit the change to BK (not easy because, as in the case of the backdoor, using the assignment operator in a condition: if (foo = 0) ... is a huge red flag to good C programmer,) and then go unnoticed for enough time that hosts in-the-wild ended up running it. A long shot, to say the least.

Re:more reason to sign patches?

[Alsee]

And this is exactly why we need Palladium or trusted whateveritscalledthesedays.
As much as people like to bash it, it would be useful in the case you described.

NO.

While you are right that Palladium-like-hardware or trusted-whatever-like-hardware could be used as you suggest, there is still absolutely NO justification to forbid the owner of the machine from knowing his own master key. And that is the central design feature of Palladium/NGSCB and TCPA and Trusted-Computing.

There is NO POSSIBLE security benefit you can get by NOT KNOWING YOUR OWN KEY. The only possible purpose to forbid people to know their own key is for DRM and user lock-in.

New hardware is fine. Forbiding the owner of the machine from knowing his own master key is purely malicious. Palladium/whatever forbid the owner to know his own master key therefore Palladium and the others are malicious.

-

Re:more reason to sign patches?

[swillden]

You're really grasping at straws here, but ok...

Absolutely not. I design and build high-security systems for a living, and these sorts of issues are very, very real. When millions of dollars depend on a key's integrity, this stuff *matters*.

For that matter, if there's a way to compromise keys in bulk, the individual keys don't even have to be very valuable to make the attack worthwhile.

Say the paper-key comes sealed from the chip manufacturer.

Now there are a dozen points during the manufacturing process where the key could have been compromised, not to mention many, many hands that could have opened the paper enroute, copied the key and generated a new "sealed" copy to pass along. The processes used to generate, print and mail credit card PIN numbers demonstrates just how hard it is to maintain security in a process like this, and those numbers aren't all that sensitive.

Even if we stipulate that the manufacturer is able to produce sealed documents without any possibility of compromise, how will you, the end user, be able to distinguish between the real thing and a well-executed forgery?

And if the paper-printed key was "stolen" back within the TCPA chip manufacturing plant then it could equally have been stolen within the chip manufacturing plant no matter what.

Now we're getting to the meat of it. Here's the crux of the matter: In a well-designed security system, the crucial keys *never* exist in cleartext outside of secure hardware. In the case of TCPA this is really easy because the chip has the ability to generate its own keys. This means that they can't be stolen at the manufacturing plant without essentially destroying the chip (well, barring side-channel attacks, but it's fairly easy for the manufacturer to protect against those. If you're not familiar with the concept, look it up. If you like security stuff, it's fascinating).

All high-security tokens utilize this same concept of keys that never leave the device, because it's really the only convenient way to maintain security of the keys. For the times when keys *must* leave the device, and cannot be encrypted (for example, during initial key exchange of symmetric keys), good systems still don't let them out in the clear. Instead, we use "secure key splitting" to break the key in to n parts, such that all n are required to reconstruct any information about the key, and those parts are then transferred separately, via separate routes to different people and kept apart until they can be entered into secure hardware, and reassembled there.

At the end of the day, the real bottom line, however, is that it is not only potentially bad to know your key, it's completely unnecessary. Banks use 3DES symmetric keys (called Zone Master Keys) to transport messages worth billions of dollars every day, and I guarantee you that no human has *ever* seen a singe bit of any one of those keys.

No, what you want, as the owner of a key, is to be sure that you can use it and no one else can. Having it stored in a secure device that will never reveal it, but will employ it on your behalf, at your request is the best way to do that.

The problem at hand (that TCPA makes DRM possible), actually has nothing to do with whether or not the owner has a copy of the endorsement key. Your claim that you could use the endorsement key to decrypt DRM-protected data is incorrect, because the endorsement key will never be used to decrypt any data (to use it for decryption would be to destroy its security as an endorsement key. Think about why that is; it's interesting).

Here's how a TCPA chip might be used to implement a DRM system:

1. The content provider sends a challenge value to your computer.
2. Your computer uses the TCPA TPM_Quote primitive to ask the TPM to generate a signed message that incorporates both the challenge, the current contents of the Platform Configuration Registers (PCR) and a Binding Key. The message is signed by some ke

I'm impressed

[Anonymous Coward]

This is why I think OS is the ultimate meritocracy, those who shine bright shine brighter than all, illuminating the darkness and bringing out those who lurk in the shadows.

So how do we know that there is only one?

[dreadlord76]

Ok, so the scripts caught an attempt to install a back door. Everybody jumps up and down and sings the praise of the mighty Open Source Movement.

What if a backdoor was installed last week, or last month, but was not caught?

The fact that this was possible once, should really make people think about the possibility of it happened ALREADY, and determine if it is necessary to hunt through the code for a systematic review.

Instead, all we get is Microsoft Bashing...
Ugh

Re:So how do we know that there is only one?

[mad flyer]

Let me try to understand you...

Your saying that it's bad that some hack get caught before spreading in the wild, and Microsoft is better because at least it let backdoor getting out and nobody can audit for troubles ?

Don't get it...

You are the kind of people that make accidents happen.
You don't point the fact that the system worked by preventing a hack. You just say that the fact that there was an attempt means the system is unsafe...

It's kinda biased I think...

yet another reason for (CONSTANT == var)

[Anonymous Coward]

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.

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

In this case, it would make an attempted root hole more visible, as (0 = current->uid) would not compile.

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

[Anonymous Coward]

doesn't lint check for this? If checkins were automatically run through lint something like this would have been easier to detect.

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

[GridPoint]

The following code does the same, without using the "C considers NULL to be false"-hack. It is easier to read and maintain (less bug prone):

if( (fp = fopen("file","w")) != NULL )
{
file opened correctly, so use the fp pointer.
}
else
{
error handling here
}

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

[spitzak]

No that would not help one bit. The code is designed to look like you are testing to see if current->uid is equal to the root uid. I doubt putting the root id in a variable, or using a macro/enum/constant like ROOT_ID would make the slightest difference in the ability to catch this.

Please tell me any plausable reason why the mistake is easier to see in the second case than the first:

if (foo = 0) {...}

if (foo = x) {...}

Re:Microsoft

[iabervon]

The actual lines of code and the method by which they got there were far too clever for either Microsoft or SCO. In particular, it looked like a check for an invalid combination of flags by root, but would actually set the process to root in the case of the invalid combination of flags (and the error return value would be overwritten).

The intent was probably that a CVS user get the bad version, work on other stuff, and send the diff (including the bad lines) to a maintainer in an otherwise good patch. However, the BKCVS gateway got confused by someone other than it changing the CVS, and complained, and Larry McVoy pointed out the issue, someone asked what the lines were, and other people figured out what they'd do. Now, of course, if someone had gotten that bit accidentally and submitted it to a maintainer, they'd notice, so the attempt seems to have failed.

Linus pointed out a benefit to using BK: even if the official BK repository were changed, he doesn't pull from it (because his local copy has all of his changes), and he would get an error the next time he pushed to it. The repository that would have to be attacked is actually his local disk, behind a firewall and not set up for anyone else to access at all.

If RMS wants to rant about revision control systems, he'll need to say that CVS needs to be replaced with a more functional alternative (Subversion, perhaps), not BK.

Re:Bad News

[fanatic]

It's the quiet ones you've got to watch...

Yes, everyone who's upset about exploits they haven't heard about, raise their hands...

Re:First of Many?

[nathanh]

Will this be the first of more kernel backdoors, now that the idea is out there?

Isn't the pertinent question... was this the first?

No one is mentioning this

[Dancin_Santa]

The problem is that CVS was exploited. That's the big deal, Open Source, all encompassing versioning system.

It was Bitkeeper, the closed source, unfree, anti-community product that caught the problem.

This isn't a triumph of 'many eyes' seeing this bad code in Linux, it was a failure of 'many eyes' not catching the problem in CVS.

Re:No one is mentioning this

[mcroot]

Insightful my ass. Nowhere does it say CVS was exploited.

The code was injected into a CVS tree, the box could have been compromised in another fashion, such as a wu-ftp hole or some such thing.

So please, don't throw the word exploit around as if you have 1/2 a clue about security. It just makes you look silly to those of us who do.

Re:Daaaammmmmnnnn..

[blair1q]

Why?

What's the penalty under the law for putting a backdoor in an open-sourced software project?

None.

That's it. That's the list.

Re:Curious abot the hack, was it remote?

[kasperd]

As noted on LKML, (current->uid = 0) was probably deliberately surrounded by brackets to avoid a gcc warning of an assignment within a test.

I'm not so sure about that. Personally I would have put the brackets there even in case of a normal test. They might not be necesarry, but I trust brackets more than I would trust my own ability to remember the precedence of every operator in C.

Re:Daaaammmmmnnnn..

[Nucleon500]

Our friend the DMCA, of course. Becomming root with wait4(3<<30) could clearly be used to copy files to which you don't have read access, thus circumventing an effective copy control mechanism. Heck, I'm a criminal for telling you that.

Seriously, though - there are probably many laws by which it would be illegal. The cracker gained unauthorized access to a system and he vandalized data. And the obvious intent was to create a backdoor in many more systems. If they find this guy, he'll be in serious trouble. The guy he pretended to be could probably also sue him for something.

Why on God's earth...

[tuxlove]

...is the primary CVS repository reachable? Nobody should be able to touch it, even just to read it, except the chosen few. Or am I mising something?

Re:Why on God's earth...

[chrome]

You're missing something. They use bitkeeper, the CVS repository for people without CVS.

Its separate so they can screen CVS commits carefully.

Re:Why on God's earth...

[Anonymous Coward]

Primary Linux BK respository is at Linus' machine,
public BITMOVER version is just published replica
of that one, but it isn't primary.

There are derivatives for people who for some (political) reason don't want to use BK. One of those is BK2CVS, which gets overwritten daily
from primary data source.

That CVS is served publically via standard CVS pserver, which has a number of problems all of its own.

Nobody willing to publish source code from CVS should do it with actual primary repository in r/w mode. That way is clear invitation for trouble!

Re:guide to getting rid of slashdot ads

[dekashizl]

You're such a douchebag. A single banner ad that is a) an image, b) fixed size, and c) fixed placement on the top of the page is one of the most UNobtrusive ways of advertising possible. How'd you like popups, popunders, expanding "CLICK TO CLOSE" ads, ads with sounds, ads that try to install Gator on your PC, ads with JavaScript errors in them, etc...

How do you think /. doesn't get /.ed? Because it runs lots of hardware and bandwidth that's supported (partly at least) by money from those ads. How'd you like to pay for access? No? Then shut up and be appreciative that the ads are tastefully executed on this site, rather than trying to subvert the system that's effectively in place to give you something you like for free.

Must Read: Ken Thompsom's Turing Award Lecture

[Eric Smith]

Anyone that thinks security is easy (apparently some people still do) really needs to read Ken Thompson's 1984 Turing Award Lecture "Reflections on Trusting Trust": http://www.acm.org/classics/sep95/ As Bruce Schneier says, security is a process, not a product.

Re:Trusting Trust

[ocelotbob]

Such a backdoor is fairly trivial to ferret out nowadays. All one would have to do is to place Intel's C compiler, or some other compiler capable of building gcc somewhere in the mix. As it is much, much less likely that a) two compiler trees have backdoors in there and b) both compiler chains have the same exact exploit in them, and can detect that they are building each other, by doing so, the tinfoil hat types can be assurred that their copy of gcc is essentially mathematically ensured not to have a backdoor, unless of course there is some wide-reaching conspiracy in the computer world, in which case, we're all fucked anyways, so it doesn't really matter.

Thompson's hack worked because he was the only provider of both Unix and C. Nowadays, that's simply not the case.

And this, dear reader

[Rogerborg]

Should end the old argument about which is better, the habitual, easy to read, but easy to screw up or abuse:

if(variable == CONSTANT) { }

Or the safe version that's so much harder to screw up and which turns out to be just as easy to read with practice:

if(CONSTANT == variable) { }

Do we all understand the real world significance of this now?

If you still want to advocate (variable == CONSTANT), then please feel free to prove that no accidental or abusive (variable = CONSTANT) exist in the kernel.

The list is good reading

[erenq]

I recommend reading the original mailing list postings, they're good reading, rather better than most of these slashdot comments. Just follow the first link in the article.

Defensive coder's bullet-proofing technique

[Anonymous Coward]

At first glance it looks like the value of uid is being compared with 0, when in actuality it is being assigned the value of 0: root!

An old trick, from my days writing with C compilers under MS-DOS: to force the compiler to catch this problem, put the constant (the zero, in this case) on the left-hand side of the 'equals' sign. C doesn't allow assignments to constants, and even a crude compiler will catch this.

In other words, when you meant

(uid == 0)

and used a single 'equals' sign, instead of

(uid = 0)

you'll get

(0 = uid)

Re:Wowzers

[Anonymous Coward]

Thank heavens for diversity, peered repositories and extensive cross checking.

Re:I wonder why not a remote root hack

[Short Circuit]

On the bright side, it shouldn't be hard to search for, as far as OSS projects go. Especially if those projects are accessible via a web-CVS portal; Google caches those, I think.

Re:I wonder why not a remote root hack

[Old Wolf]

whoever owns sourceforge just has to grep all the applications for wait4 , and that may lead straight to the guy..