Slashdot Mirror
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."
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
Someday, I'll have a real sig.
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.
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.
Isn't the pertinent question... was this the first?
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?
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.
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.
Litigious bastards
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
Je fume. Tu fumes. Nous fûmes!