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."
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?
Someone has some damned big balls to do something like that...
Let's hope they're cut off.
This statement is false.
Anybody point fingers at Microsoft yet? SCO?
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.
Imagine if this had sneaked into some Longhorn code right before shipping. Many eyes make few mistakes.
this sig limit is too small to put anything good h
Sounds like a plan to get the dirty GNU/hippies to upgrade to the real BitKeeper instead of using the communist CVS gateway.
That McVoy is a smart one!
Did you know his programmers need to feed their families and pay their mortgages? Very sad situation, I hope everybody buys 10-15 licenses ASAP.
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.
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!
Damia
the kernel developers should really come up and implement a plan to maintain kernel "safety".
Well it got caught didn't it?
It's the quiet ones you've got to watch...
'There is a Light that never goes out.'
I'll call ESR, he's got the guns.
You guys get Linus and make sure he brings Tove, since she could probly kick all our asses.
Once thats done we'll Larry McVoy, by this time hopefully he will have the IP of the slimeball.
The Pose rides at Dawn, we can kill some Trolls along the way.
Did Glenn Beck rape and kill a girl in 1990? gb1990.com
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
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.
You honestly have no idea what a "monolithic kernel" is, do you.
Or HIBT.
Yes, everyone who's upset about exploits they haven't heard about, raise their hands...
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
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.
Isn't the pertinent question... was this the first?
When you troll like that, I think you're supposed to have some throw-away account so you can collect karma in some misguided intent to abuse the moderation system. I hear that's what all the kids are doing these days.
:)
(wait - am I supposed to say "here goes my karma" at this point?)
My God! It's full of stars!
1 x 4 x 9
That monolith... oh... kernel.... right...
Stop the Slashdot effect! Don't read the articles!
Keep reading the thread - you'll read a bid of Linus, and a comforting explaination of whats happenin' back there.
The Ultimate Backdoor, if anyone hasn't read about it:
Reflections on Trusting Trust.
You might want to doublecheck that gcc code you're compiling the kernel with...
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-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
The "backdoor" that someone attempted to submit was a local privilege elevation bug, not a remote compromise.
No more Linux for us
Yeah, because he'd rather like a closed source product where such attempts suceed unnoticed.
Do you care about the security of your wireless mouse?
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.
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.
C|N>K
I see some people posting some negative replies, or lamenting on OSS process, etc and saying how it didnt work, or how a psuedo-trusted patch would get in, if it went through proper channels, or some such crap.
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...
Microsoft insists the timing of their bounty (pay deal) on (for) virus writers (hackers) "entirely coincidental" (damned convenient)
Curiosity was framed. Ignorance killed the cat.
Actually Linus has an opinion:
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
-- jaf
...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?
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...
/. 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.
How do you think
It doesnt have to do with the development process.
Besides, the linux kernel is considered to be a monolithic kernel as well.
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.
The vandal who put this in the CVS code tree obviously had a lot of skill.
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!
Dr. Demento On The 'Net!
So, if source code for a trojan is inserted into a GPL's project and assuming the author of the Trojan knows the trojaned program is a GPL project, does that mean that the Trojan is technically GPL'ed
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.
If you were blocking sigs, you wouldn't have to read this.
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.
Of course, at some point, we do have to trust someone.
Ken Thompson wrote an original speculative essay on this for CACM 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.
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
and used a single 'equals' sign, instead of you'll getI wonder if there is not a way to defeat such a method?
For those who didn't read the article by Ken Thompson ( read it here) a compiler is corrupted so that it inserts a bug into all compilers that it compiles, and the purpose of that bug is to insert a bug into another program (such as login) when it compiles it (such as accepting a certain password as the root password)
Both bugs have to be a pattern based search method. They look for some string or some sequence of characters that the original hacker believes will be consistent in future code, and then make their modifications.
Running the code through a obfuscating precompiler that both randomized variable names and added random white space would potentially remove any pattern that the trojan was looking for.
Can anyone think of things that I missed (or ways to make the trojan continue to work in the face of obfuscation)
the obfuscator would, of course, be written in an interpreted language... ( [raises pink to corner of mouth and channels Dr. Evil] whose interpreter has of course been corrupted so that it inserts naughty limericks into every application it "obfuscates".... MUWAHAHAHA... MUWAHAHAH....)
--
Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
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.
I used up all my sick days, so I'm calling in dead.