Linux Kernel Back-Door Hack Attempt Discovered 687
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:Bad News (Score:3, Informative)
Well it got caught didn't it?
It's the quiet ones you've got to watch...
Re:3 cheers for monolithic kernals (Score:2, Informative)
You honestly have no idea what a "monolithic kernel" is, do you.
Or HIBT.
Re:First of Many? (Score:1, Informative)
Re:Yet another reason to use open source software (Score:3, Informative)
Calm down, calm down... (Score:5, Informative)
Trusting Trust (Score:5, Informative)
Reflections on Trusting Trust [wbglinks.net].
You might want to doublecheck that gcc code you're compiling the kernel with...
Re:Well well (Score:5, Informative)
Re:So how do we know that there is only one? (Score:2, Informative)
I don't know if your trying to spread FUD but I'll bite. Each of the patch on the kernel that goes into the main trunk is inspected by the maintainers, and Linus gets the last word. Even the other maintainers go over the code so No it hasn't happened already and this person was an idiot for thinking it would get anywhere near the main tree.
As noone else seems to have pointed out yet... (Score:5, Informative)
The "backdoor" that someone attempted to submit was a local privilege elevation bug, not a remote compromise.
Comment removed (Score:5, Informative)
doubters are forgetting the foundations of OSS (Score:5, Informative)
this couldn't be further from the truth, you are all forgetting many things, #1 - the checking scripts run daily now, and Larry has mentioned he's going to step that up, still fixed within 24hrs is a damn good response time! closed-source could never be this fast.
#2 - all this talk of peer review, saying it didn't catch this or whatever nonsense, yes in a way it did, and whats more it's exactly what will keep semi-valid attempts or those through "proper channels" out of the code. You forget, millions of people around the world review this stuff, and someone, somewhere will find it relatively quickly, and not just because all the good developers (which is most of the millions) really LIKE linux and do their utmost to protect it, and ensure that no twits do things like this.
on the oft-side billions to one chance someone does something stupid like people said hire someone to do good patches for a long time, get trusted, and submit a patch with this kind of code in it, well, first of all, this is just stupid, it would take years to get that trusted from "zero", second, even assuming all that, the code would still get caught very quickly.
Like I said, someone, somewhere is gonna notice real quick, because the millions of us out in the world really happen to LIKE linux, and protect the kernel most of all, and I'm sure as the code worked its way into the tree, one of the people would catch it, and I'd be willing to bet several would see it at the same moment, including Linus, et all.
You simply can't pull a fast one over the great coders we have, these aren't your average coders, and remember, not just them, but all of us, really, in a way, put our heart and soul into supporting Linux, its a confidence we dont share lightly, the kernel is the most protected of it all, yes, for obvious reasons, its the most critical code.
But even outside the kernel, remember millions of people around the world are reviewing code 24hrs a day, every day, and posting notes about issues, patches, etc.
It's simply much harder to get by all that. Like I said, and I'll say it again, someone's gonna notice, and probably LONG before it even gets into the main BK tree, because even those reviewers ain't slouches!
Closed source has a smaller review team, and I know for a fact internal developers add back-doors to code all the time. I know many closed-source coders (not necessarily personally) that as a matter of habit throw in back-doors into every piece of code they write, because they hate their job, and the people they work for, and hate the product. Since very few people ever review the code, things can sit there indefinately and never get found.
remember this is a work of pride, something the community really cares about, we really want to see it succeed, and not have the issues like this, or that others have, we want to protect it at all costs, in any way, to ensure a good future, and protect the users out there.
remember, we're users too! If it means that much to you, wouldn't you be checking it too? damn straight! This is exactly why the OSS model is so damn important,
and its exactly why Microcrap, SCO, etc will never "get" it. I'd even add Intel to this list, because I think AMD is really "getting" it.
summary - we like it, we care about it, and aint no way we gonna let some dork attempt to ruin something we've worked so damn hard to build, not just for ourselves, but for everyone, its a matter of pride.
and yes, anyone found out (and they will be!) doing this shit is gonna get their ass kicked into next week...
Re:Well well (Score:5, Informative)
All of the vulnerabilities I listed made it into official releases before being patched. The bug this story is about didn't make it one day in the source tree, let alone into an official release.
Sorry about the Protegrity one, I must've linked the wrong one. I was looking for this [cert.org] one (the one exploited by the slammer worm).
Linus's opinion (Score:2, Informative)
On Wed, 5 Nov 2003, Andreas Dilger wrote:
>
> Granted that this was not a break in BK itself the event is still alarming.
> It makes me wonder if there is some way we can start using GPG signatures
> with BK itself so that you can get proof-positive that a CSET annotated
> as from davem really is from the David Miller we know and trust.
A few things do make the current system _fairly_ secure. One of them is
that if somebody were to actually access the BK trees directly, that would
be noticed immediately: when I push to the places I export from, the push
itself would fail due to having an unexpected changeset in the target that
I don't have on my local tree. So I'd notice that kind of stuff
immediately.
And that's likely to be true of all other BK users too: the public trees
are just replicas of the trees people actually _work_ on, so if the public
tree has something unexpected, trying to update them just won't work. You
just can't push to a tree that isn't a subset of what you already have.
So any BK corruption would have to come from the private trees, not the
public ones. Which tend to be better secured, exactly because they are
private (ie they don't have things like cvspserver etc public servers). I
suspect most of us have firewalls that just don't accept any incoming
connections - I know I do.
I think it's telling that it was the CVS tree and not the BK tree that
somebody tried to corrupt.
Linus
Re:Yet another reason to use open source software (Score:3, Informative)
[emphasis added]
So in fact, it was the power of BitKeeper, or at least BitKeeper's authors, that prevented this, not CVS itself. Looks like closed source saves the day once more...
Re:3 cheers for monolithic kernals (Score:2, Informative)
It doesnt have to do with the development process.
Besides, the linux kernel is considered to be a monolithic kernel as well.
Re:Daaaammmmmnnnn.. (Score:3, Informative)
Ohhh, I can think of some.
Fraud and destruction/misuse of private property come to mind. And those are pretty much universal...
Re:Microsoft (Score:5, Informative)
It was a subtle change but I think it would have been caught if it had been submitted to Linus. He does review code and often catches mistakes. In this case assignment was used in a condition. To good C programmers this is bad taste. I noticed that right off and I haven't written a line of C in about 6 years. Linus isn't just a good C programmer. After half a decade of watching him catch stuff like this in just his public LKML messages, I'm convinced he would have seen this if he were reading braille hardcopy of it from across the room while drunk.
Re:So how do we know that there is only one? (Score:3, Informative)
We can only ever know about the first two kinds, of course.
Open Source software has had a few of the first kind, and this is one of them. It has had a very, very, very few of the second kind (the classic compiler backdoor is the only one I know of).
Closed source software has had some of the first kind, and quite a few of the second kind.
So, which type of software development is more likely to have the third kind? We can't know for sure, but we can be pretty confident that if there aren't any long-term-but-eventually-found backdoors, there aren't any never-found backdoors either. Likewise, if there are many long-term-but-eventually-found backdoors, there are likely to be a few sitting around that are never found.
Re:Yet another reason to use open source software (Score:3, Informative)
No, not really. It's the scripts [iu.edu] written neither by BitKeeper nor by the authors of CVS, but by some developers to allow those unwilling to use BitKeeper to get access to the latest modifications...
I wonder why not a remote root hack (Score:5, Informative)
It's a clever backdoor, and might have gone unnoticed, if not for those those good automated checks in the BitKeeper-to-CVS gateway. Notice that the particular coding style is a common C gotcha (using "=", assignment, instead of "==", comparison). 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! The gcc compiler is good about warning for this, except that this too has been defeated: as mentioned on the mailing list, notice the unusual high number of parenthesis around this expression. That high number of parenthesis has the effect of suppressing the gcc compiler warning.
So, whoever did this obviously knew what they were doing and tried to obfuscate it. As somebody else mentioned on the kernel mailing list, if somebody is going to put in a backdoor like this, why not make it a remote root hack?
As it is now, the above hack is only locally exploitable. A process on the local system still has to call the wait system call with that particular combination of flags, in order to trigger the exploit and get root. To my knowledge, no known applications do this, because the combination of flags is supposed to be invalid.
If a spammer or somebody else was trying to backdoor the Linux kernel in order to gain a large number of machines to infest, then one wonders why they didn't put in a remote root exploit. It seems strange to go to all the trouble. Since this backdoor attempt has been caught and blocked, security will now only become tighter, and they might not ever get another chance like this.
Maybe it was intended to be used with another application, also backdoored in the same manner? It might be insightful to scan other open source applications and search for this particular usage of flags to the wait system call.
In any case, I'm glad this hack was caught!
Re:Daaaammmmmnnnn.. (Score:3, Informative)
Re:yet another reason for (CONSTANT == var) (Score:2, Informative)
Re:I wonder why not a remote root hack (Score:3, Informative)
The brackets are necessary to even get the thing to compile as the precedence of '=' is below that of the logical operators.
bash-2.05a$ cat > test.c
int foo() {
extern int x,y,z;
if(x>y && z=0) x=y;
}
bash-2.05a$ gcc test.c
test.c: In function `foo':
test.c:3: invalid lvalue in assignment
YAW.
Re:3 cheers for monolithic kernals (Score:2, Informative)
One obvious advantage to a microkernel is that portions of the kernel can then be (carefully) swapped out to virtual memory on disk, whereas monolithic kernels generally cannot (just don't page out the pager, or disk I/O system!). This is good, because those microkernels tend to run significantly larger than a comparable monolithic kernel. Microkernels tend to be handle to handle real-time scheduling constraints better than a monolithic kernel can because of the nature of the thing.
Now, aside from SCO UNIX products, I don't know of any OS that is completely monolithic these days. Linux has kernel threads and run-time installable modules which are rather un-monolithic from a purist stand point. And from the microkernel camp, we have NT and OSX, which runs their entire kernel in the highest priority level for performance reasons, and in NT's case, have a rather heavy microkernel. Hybrids, the whole lot of 'em.