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 horrible. Thank heavens BitKeeper recognized the failed attempt to alter the code of the kernel. This is something the kernel developers should really come up and implement a plan to maintain kernel "safety".
YOU'RE WINNER !
Another lame blog
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.
As usual, Microsoft is overplaying its hand. They should stick to astroturfing slashdot.
who are those slashdot people? they swept over like Mongol-Tartars.
If it was SCO, they would have just planted some of their source code... Oh, maybe they did.
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.
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.
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
Hats off to the people who check and report this kind of stuff.
+-+-+-The folowing statement is true. The previous statement is false.-+-+-+
Will this be the first of more kernel backdoors, now that the idea is out there?
how many such holes are in Windows? They could never keep track of everything in the chaos at MS.
This is why monolithic kernals, liek the OpenBSD kernel are bettar. Since Theo dee Raddt is the only one who can edit the code, he is the only one that can add or remove back doors and exploits, so this kind of thing would not happen.
That would be giving them.........way too much credit.
Neither one of those companies has the talent to pull this sort of thing off. It was probably some spammer looking for another couple of million hosts to hide behind now that Microsoft is posting bounties for compromising Windows code.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
typedef unsigned int csNetworkSocket;
#if !defined (CS_NET_SOCKET_INVALID)
// This is the stuff we stole from SCO, keep it hushed
# define CS_NET_SOCKET_INVALID ((csNetworkSocket)~0)
#endif
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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.
Think about how often your own code gets reviewed, debugged, optimised - not necessarily by you, but by Joe Coder on the same project or Wilma Coder some time down the road.
I doubt that someone sociopathic enough to work on something for years under a legitimate guise, then "one day" would be able to keep it together long enough to pull off the kind of coup you're proposing.
No, I tend to think that folks of this bent are found mostly among the crowd of virus authors.
Oh man, if my boss sees this, thats gonna be it right there.. No more Linux for us
n/t ^_^
NSA Key
Or maybe the Fedorinati. (A secret society which threatens to take over Red Hat.)
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.
Does GCC have a warning for this code? (and does it also have the option to treat warnings as errors?)
Bitkeeper... caught the problem
Err, no. One of the kernel hackers watching the changes caught the issue.
You can do the same thing in a few other operating systems. I believe one of them is a unix of sorts but I do not know which one nor have I gone to look for it.
Please, stop with all this bogus hype!
From the writeup:
in fact it was the BitKeeper CVS export scripts that detected the unauthorized modifications to CVS
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...
Kudos to Larry McVoy, owner of BitKeeper, who caught this little piece of interesting skullduggery.
All about me
The headline makes it sound as if there's a backdoor in the linux kernel. The only backdoor that's open belongs to CmdrTaco.
Cleanse Your Soul
Those of you not as well versed in the lore as the rest of you would do well to read the legend of Ken Thompson's backdoor login compiler compiler.
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.
The scripts used to sync bk and cvs are what caught the problem. I don't think this had anything to do with CVS or BK. It was just some scripts Larry was using to sync the two.
Your childish tricks will not work around here.
And please return the check to Bill, you failed.
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?
Sounds like it might be time for a quick audit. Like looking at every instance of "current->uid" to see if the uid is a LHS.
Don't forget things like "current->uid -= current->uid" and similarly with exor, bitwise and, etc. (That's why any occurrence of current->uid as a LHS is suspect.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
what a piece of crap you wrote man..
Isn't the pertinent question... was this the first?
No. I'm pretty certain that the CCC once smuggled in a backdoor to the login prompt. That must have been pre 1994.
I can't find any more information on this. Does anyone have a link?
It looks like the janitor(Dave) over at bitmover noticed the tampering and this clown is taking all the credit.
Cleanse Your Soul
We'll see if they pounce on this. If so, expect something like "See? Open Source projects are inherently vulnerable to hackers infiltrating and corrupting the code base" This is not good. But it is a good thing it was caught and never got released!
--
om Shanti
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
Thank heavens for a BitKeeper. I'm glad they took measures to secure such a thing from happening before it did. Only smart minds in the linux community could do something like that. Screw closed source.
"The ironing is delicious!"
It was the closed-source Bitkeeper software that caught the attempted code sneakiness.
+4 Insightful my ass.
I always sort of wondered what was stopping people from putting a "virus" or something into the portage tree that would knock out my system with I updated it.
Unfortunatly I don't think it would be very hard for someone to insert something that could totally hose my system.
This kinda scares me.
-Mary
ummm... once you scroll down to the comments you can't see the banners. how do you think they pay for the bandwidth, electricity, equipment, backup tapes, diskspace and maintenance labour you're useing on their server?
I copied from here...
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Score:-1, Utterly pathetic
Guys, the code was intentionally modified by LM to better sell his incoming new feature of signing transfers.
how do you think they pay for the bandwidth, electricity, equipment, backup tapes, diskspace and maintenance labour you're useing on their server?
Felching schoolteachers?
Writers imply. Readers infer.
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...
World would have been a much better place if talent like this has been diverted for constructive purpose rather than coming up with things like this.
Oh man, that's funny because no one on Earth could even reasonably have such a whacked out point of view. I especially liked this part:
:D
Contrasted with the closed source, non-geeky software house Microsoft, Open Source has a long, long way to go.
http://www.bernd-leitenberger.de/bill-gates.jpeg
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
You combine an essential failure to reason with a wonderfully concise lack of insight.
In truth it wasn't the nature of the two systems (BitKeeper vs CVS) but the very nature of an interface existing between two systems.
It is (verrily 8-) the programatic equivlant of many eyes in action.
Multiply that, your core error, by the straw-horse of communitizing the open-vs-closed nature of the two products.
It is the particular script that spanned the gap that "caught it".
But further still, the "many (human) eyes" never played in to the operation. Someone electronically installed a hack and it was caught by a script (which script may or may not have underwent peer review). That that same hack would have then had to face peer review only doubles the effectiveness the the kernel's management paradigm.
So "yea, it was caught by a script" yields NO POSSIBLE VALID INDICTMENT of open over closed source models.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
it wasn't SCO trying to sneak in some of it's code so it could point to it and say... "See? We TOLD you the kernel had our code in it!"
But seriously, it's a credit to the ppl working on the project that this attempt was caught. I am not toooooo worried that other attempt at malice have gone unseen as just too many people are looking over the code all the time. Any maliciousness would have to be buried under several layers of valid and useful code (not sluggish crap or slop, either).
After hearing of security holes in every OS AFTER the fact, it's nice to see one caught before it even happened. And a non-accidental one at that. Kudos to the team!
If SCO's case ever hits the courtroom, this incident might mean that it's impossible for them to claim anyone knowingly added SCO property to the Linux kernel.
For all we know, they could have been doing it themselves...
To Terminate, or not to Terminate, that's the question - SCSIROB
This is the *Linux kernel*- arguably the most watched open codebase in existence-
And there's questions about whether this is the first time?
IMO the positive "peer review" aspect of open source just doesn't trickle down to smaller projects.
I browse at +5 Flamebait- moderation for all or moderation for none.
I'm so tired, for a second there, I thought you were dissing Burger King.
I believe several of the BSD's use CVS. I wonder if their code have been hit as well or is it just Linux that was targeted?
Might be a good time to check them to see if somebody decided to pull a similar exploit against other OSSs.
I prefer the "u" in honour as it seems to be missing these days.
Under normal conditions with office politics involved, yes, but this would be a rogue operative. Think Splinter Cell. Actually, don't think Splinter Cell. Sam Fisher's micromanager won't let him walk on the damn sidewalk.
Anyway, Microsoft's a lot like NASA. Full of geniuses, performs incredible feats that nobody else can, constantly makes staggeringly stupid mistakes. So don't underestimate the potential of a lone Softie too junior for management.
Back-Door Hack
Was the password "Jeff"?
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.
And now the pserver @ kernel.org is down so i can't fix the problem.
A few thing is alarming about this:
* the patch is very clever.
* the timing is very good (2.6.0 release soon).
* the primary site for the linux kernel is in some way compromised.
yes!!! lynx is the best browser ;-) i only see ads on google, and don't really mind those. they're not bigass javashit popups
well actually there is one other place: yahoo groups. except i don't see the ads themselves, but have to constantly "click here to continue to message" because their code seems to detect i'm not loading the images. so i pretty much avoid that place like the plague...
if anyone else hates yahoogroups because of all their lame ads you *have* to click through, check out this nifty perl script: yahoo2mbox ... you can just let it download all the msgs you want to read and browse them offline in mutt or whatever.
by drinkypoo (153816) ... ...Why do you mock ...with a username like that?
Can you drink the tap water in Moscow yet, Comrade?...
This would never happen in OpenBSD. Oh wait, it allready did.
but I trust brackets more than I would trust my own ability to remember the precedence of every operator in C.
I consider the parenthesis to be two character comments.
Ignoring ourselves, its also a matter of trusting others. I've seen people break perfectly good code by replacing a multiply by a power of two with a shift in a non-trivial expression not realizing the difference in precedence between multiply and shift. I've learned to write code others will have an easy time maintaining it so I am free to do other things that interest me more.
...some of you always start bagging MS.
VENI, VIDI, VICI, DIXI
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
Like some months ago when the FSF got root'ed and they spent a few days trying to figure out if any GNU source was compromised?
Before that didn't OpenSSH briefly have compromised source? My recollection is more fuzzy on this one.
And this is just high profile recent history. Imagine the stuff waiting for folks at SourceForge in smaller projects maintained by "less talented" people.
Hey, how about those hidden racist comments in Perl scripts?
&debug("[$.]: ${_} -> $ent->{$_}");
dark ebony black underground giraffes with some money inside and outside parentheses are sent to entertain for money while shooting arrows at rich quotation marks while winking?
I am Monkey, the Great Sage, equal of heaven!
In general I agree with your sentiment that readability is very important but I don't see a readability issue in this particular instance. When I first encountered (0 == n) rather than (n == 0) my thought was that's odd. Odd as in non-typical not odd as in perplexing. Is (n == 0) more readable or does it merely mimick the style of the textbooks we read?
Pure genius. Let's see how many flames roll in from the satirically-challenged... ;-)
a true black ops set-up....
why not?
The Art of War, right?
bring your opponent to your level
A number of problems exist in the above post.
1) It is not acceptable to call someone a 'douchebag' just because you don't agree with them. That statement also fails to address the argument made by the original poster - that text ads would be less intrusive and more effective than graphical popups.
2) Although it is true that a fixed-size banner is less intrusive than a popup, it is more intrusive than text ads, and a quick search of the www.alertbox.com archives will tell you that text ads are more effective, and that people don't actually LOOK at banners - so blocking them costs Slashdot nothing.
- Ergo, the abolition of graphical banner ads on Slashdot would be of mutual benefit to both the community AND advertisers.
3) A false dichotomy: the choice isn't "Banner ads or no Slashdot".
- There are other types of ad.
- There are other sources of revenue as well as ads.
Makes you wonder how many backdoors have slipped through in windows, in Linux anyone can discover a backdoor. Who discovers them in windows?
Well, I'm hearing a lot on here about "hey, if this happened to open source once, it may have already happened or it may happen again" ... sure... but wait a minute, wasn't the halflife 2 source code leaked/stolen a while ago? Propietary code, no? Who is to say that they didn't add a few dozen back doors into it while they were at it, mmm?
The risk of this happening to open and closed source is roughly the same, and the benefit of open source it that it can be spotted...
#if !defined() is perfectly find with the GCC pre-processor. I have no idea if it's C[8|9]9 compliant though.
That one wouldn't get very far, now would it...
I offer 25k open source dollars to everyone submitting a guy who attempted this. :)
What annoys me now is that some games developers (e.g. Rare) are being called "2nd party" because they are owned by a manufacturer.
The correct terms are: 1st party = manufacturer, 2nd party = end-user, 3rd party = anyone else.
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
wat?
I bet the hacker is Bill Gates :P
Does anyone remember that choice item, which was used as the password for a backdoor coded into asp some years ago by a witty Microsoft engineer? I was sitting next to a friend of mine as he cracked a local online store with this vulnerability to see if it actually worked. He was a decent guy, Linux fan through and through and informed the company about the hole.
But what if he hadn't been?
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.
But what about the penguin? It's as black as it's white.
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.
If you are assigning the value OVERRATED to ALIANWARE then "=" is correct.
YUO == BIOTCH
There have been several now.
Looks bad? Think about it.
Each one I've heard of has been detected, corrected and publicised within hours. We don't know about any that haven't been found, of course, but I haven't known of one that went undetected for even a day. If it was easy to slip in a deliberate security hole that escaped initial detection we would hear about holes that were detected only after months or more.
This has been a test of the proposition that all those eyeballs don't realy improve security because most don't realy read the source. The proposition has failed.
All those eyeballs make for an almost certanty that at least one will take a critical look.
That is all it takes.
oh bugger! I snuck it into this other o/s ok, why can't I hide it in linux?!
those kids should look whom they are messing with. In fact, they are messing with the most l33t people available in the world right now.
Let's see what comes next %)
Very funny. I sure hope nobody takes this seriously. :)
Maybe someone should grep the source for "uid[ \t]*=[ \t]*0[^0-9]" and inspect any matches, just in case?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Hey, this sounds like that piece the guy wrote comparing Open Source to Nigerian Spam!
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.
We saw the code that was used to gain root access locally on the machine. Perhaps the bit of code (buried elsewhere in the source) that allowed for remote access as a normal user has yet to be found, no?
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.
Given that I don't understand the code in the slightest (well I understand the assignment and user id 0, but not what __WCLONE or __WALL does or relates to) how would a standard user have been able to get him/herself root?
Avantslash - View Slashdot cleanly on your mobile phone.
Turns out you need an ACM subscriptiong to the link to the PDF above.
Ken Thompson has been kind enough to post a link to a free online version in the classics library at the ACM.
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 getThey screwed up the Matrix, now they're trying to screw up Linux too!
This dispels a lot of the FUD surrounding whether Linux kernel maintainers can be relied upon to detect such false entries.
In a lot of ways, this is a Good Thing, in that it proves, conclusively, that Linux' QA works and works damn well.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Plenty, probably, but that's irrelevent anyway. This person wasn't authorized to put anything in, and there are plenty of laws against unauthorized "hacking."
I would imagine putting a backdoor in an OS project is legally quite the same as in a proprietary one.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
My God, it's full of source!
Escher was the first MC and Giger invented the HR department.
Actually, give it a day.
I'm sure SCO will claim this was copied from them as well.
"if not for those those good automated checks in the BitKeeper-to-CVS gateway."
The funny thing is if all the kernel hackers had adopted BitKeeper? Those gateways wouldn't have been necessary. Let's all thank Stallman for that.
(NT)
The only way to get the code to execute was to actively try to break the copy protection on Word 2.0. If you were running under a debugger and had patched out the first two of the three anti-debugger checks, that message would be printed out, and Word would start randomly reading data off the disk.
Peter Norton found it by looking at the word binaries on the disk and put it into his column, and Microsoft had to pull it immediately.
Needless to say the intern involved never came back to Microsoft.
So what's your point? That consumer operating systems have to ship with the default logon as root?
Maybe the Dept. on this one should be "The Empire Strikes Back"
Can someone post the source diff that the hacker tried to get into the tree?
many years ago when easter eggs in programs were all the rage, there was this one guy who programmed an easter egg with a guy mooning you from inside a VW bus.
From excellent karma to terible karma with a single +5 funny post...
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.
Or Monotone, perhaps.
Monotone is a new revision control system being developed by Graydon Hoare at RedHat. It's notable for having cryptographic hashs and signatures implemented through the entire system.. each delta in the archive has a signature associated with it, as does each bit of information about the delta.
I'm not sure how well such a system would perform, but there's no sneaking data into a system like that without subverting (sorry) someone's private GPG key.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
or do i smell the stench of M$ somehow on this. A) you'd have to be pretty skilled to know even how to code for the kernel and to exploit it in this way. We may take this knowledge for granted here on /., but cmon people, the guy needed "5K1llz". B) Then, he needed a motive. What better way to keep your product on top than to prove that your enemy is riddled with a security hole worse than the the Nimbda worm?
This would most likely be a "test" run, since they would be stupid to think that no one would pick this up. They just wanted to see if it was possible. Now that it is, we'd better watch out. They will be subtle next time.
Clearly, the best way to get a remote backdoor is by making two changes, each of which is insufficient to garner attention but which, taken together, constitute the entire exploit.
The complementary step would be to try to get the priviledge elevator installed in some system component so that together they could be used as a remote bakdoor when a vulnerable kernel was running a compromised service.
Time to examine recent paches to common daemons like Apache, Samba and ftpd to see if there's anything which might take advantage of such a hole.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
(n == 0) doesn't mimick the textbooks, it mimicks the natural language. "If n is zero..."
(That's English, but I don't know of any language where the normal order is reversed, except for Yoda-speak.)
That's what makes it more readable.
Why use a back door, when the Windows is open?
I 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.
...not only are you a troll, you can't even make up your own stuff, you have to use someone else's.
PHEM - party like it's 1997-2003!
I couldn't help thinking that if this kind of attack was done within the closed-source BitKeeper instead, and we didn't have open sourced CVS to ferrit it out - it might never have been caught.
In Soviet Russia, back-door hack attempts hump YOU!
I am the Russian Humper !!
First off, white space is removed in the lexical analyzer in the earliest phase of compilation, so that part is way off base. The pattern matching would occur on something like expression trees (parse trees, syntax trees, intermediate code tuples, ...)
Secondly, the part being matched might not be alterable. If the target code is doing something like "strcmp(test_password, stored_password)", then you can't obfuscate the string "strcmp"; the symbol wouldn't be resolved by the linker.
Thirdly, the standard obfuscation tool would be well known, and the compiler could be adapted to it, or it could be subverted as well.
Fourthly, the real point of Thompson's trick was that he got people to use a trusted binary of a compiler to recompile the world. If people were distrustful enough to want to run an obfuscator, they would also refuse to trust the binary compiler sent to them by that rogue Thompson, and instead would use one of their own.
You can try to get clever, but there's no avoiding Thompson's ultimate point: there's always someone or something that must be trusted, and that is a weak link.
After all, accidental bugs that cause security flaws show the impossibility of even completely trusting oneself.
Professional Wild-Eyed Visionary
Whose university is wheening off Sun boxes. Either you have desktop machine, then you already have root access or you have an account on a corporate server, then you are probably supposed to manage it. You can go and hack your own ISP, but these are the people in the best position to monitor you and they know exactly which billing address to show up at and kick your ass *shudder*.
Why not hack NFS code instead - or better yet SSH, Apache, gcc and so on? This exploit is so ineffective that I wonder if it's a bug after all.
Egad.
The Bitkeeper side of things wasn't
touched. Only the CVS export was
cracked.
Yes, let's all thank the zealots
for making this possible.
Seriously, try to know what you
are talking about.
Couldn't someone just slip nefarious code into the source they are hosting on their mirror, then compute new hashes so that everything appears legit? You could also rebuild the binaries that you are hosting to include this evil code. And even if you are not mirroring, the GPL lets you create your own distro as long as you publish source. Just add the nasty code, publish it, and trust that none of the users will go hunting for problems. After all, it was the source MAINTAINERS who found this particular attempted exploit, thanks to some tools they were running.
I'm certainly no expert on Linux mirrors and the like. Does anyone know if there is a way to prevent what I describe?
You exaggerate a lot; obviously you have never worked in industry.
No, I exaggerate a little and have worked in the industry for 10 years as a code monkey. I've been up the totem pole from the bottom to the top - programmer, lead programmer, project manager, and IT director.
When I was a peon, I watched marketing take over development and make a lot of numbskull decisions not unlike the ones I described in my last post. I've worked with companies where company policy forbid them from making simple no-brainer decisions just like the example we're discussing.
If you haven't seen crazy stuff like this, then I doubt you've worked in the industry very long.
It's the quiet ones you've got to watch...
While you're watching the quiet ones, a loud one will fucking kill you! -- George Carlin
boldly going forward, 'cause we can't find reverse
If someone broke into MS and started altering code, people would talk about how unsecure MS is, but people seem to gloss over the seriousness of this break-in.
wouldn't it be good to include the users gpg pki sig with the code they send in, and if linus or anyone else modified it, they would sign their diffs or the code itself? Not inline, but a seperate .asc
Thank you for addressing my post. Let me respond to your points.
1) While I did feel a tiny bit bad about it, I called the poster a douchebag not because I don't agree with him, but because he is spreading harmful information that has the potential to negatively effect all of our ability to access this site for free and via the high bandwidth connection it uses (off-topic in a discussion about a Linux kernel back-door, by the way). I'm all for open discussions without name-calling, but this went beyond creationism/evolutionism to something more akin to "how to avoid speed traps near schools" which are in place to make the world a safer/better place.
2) First of all, saying "people don't actually LOOK at banners" is just plain ridiculous. Some people do, and some people don't. With TV, some people watch commercials, and some go make popcorn and take a leak off their roof. Text ads may generate more click-through, but they are more insidious in that they begin to merge with the content, something a clearly demarcated graphic ad does not do. Your evidence does nothing to support your claim that abolition of graphical banner ads would be of mutual benefit to anybody, not that you've even defined "benefit", and if you consider the issue I just raised about text ads, I can't imagine how you could make that claim.
3) I never made the claim that banner ads and Slashdot are in some kind of eternal embrace that we can't shatter. I pointed out that "the ads are tastefully executed on this site" and that you shouldn't publicly try to "subvert the system that's effectively in place to give you something you like for free."
P.S. I am posting this without Karma Bonus because I don't need to further publicize this (nor encourage wasting of mod points). I just wanted to leave a response to your issues attached to this thread.
didn't microsoft release Back Orifice
Well, I guess that means all the closed source developers have the same problem. And I guess they probably don't know either. Just wondering, if open source software facilitates somewhat easier detection of subversions, are undetected subversions in OSS, also not at a greater risk of being exploited by hackers, especially because the code is in plain view to a larger audience? (as compared to a much smaller closed source development team..)
If one wants to put on the conspiracy hat - and with this example, that doesn't seem too unreasonable, since *someone* was trying to plan a backdoor - this is a very clear warning that the security of the Linux source code needs to be taken very, very seriously.
If - just hypothetically - some Huge Opeerating System Seller - really wanted to discredit not just Linux but the whole Open Source method, what better way than to plant something like this and then step back and say "Look! Open Source is insecure! Why, with all those strange foreign bohemian types working on it, who knows *what* one of them might slip in?"
Yes, you and I know all the holes in that argument, but the pointy-haired types wouldn't.
(When properly configured).
:)
At least gcc 3.3.2 (what I tested on), yields a: "warning: will never be executed" warning if compiled with "-Wunreachable-code" (in addition to -Wall, which does not really add "all" warnings).
This is because "&& (uid = 0)" always yields false, and the "then" part of the if never runs.
Maybe its a good idea to compile OpenSource code with all these warnings turned on
I mean, at some point someone might try recompiling the compiler from the begining. And eventualy someone might simply change the compiler code so much that the back door no longer works.
autopr0n is like, down and stuff.
If they arn't running as root, they won't let you do what they want. Unless there is a local exploit....
autopr0n is like, down and stuff.
"A few things do make the current system fairly secure. One of them is that if somebody were to actually access the (BitKeeper) trees (software repositories) directly, that would be noticed immediately." - Linus Torvalds
Ummm, Linus, the fact that someone accessed the trees is defacto proof it wasn't "secure". If it were secure, it would have never been accessed. Whether you notice an intrusion in a nanosecond or a week later, an intrusion is an intrusion is an intrusion. And that, my fat Finnish friend, is not "secure".
This coming from the guy crowned as the new Jesus.
Yes, by whoever put it in.
Litigious bastards
Well, this was posted to cnet news.com: Attempted attack on Linux kernel foiled By Robert Lemos, CNET News.com Friday, November 7 2003 10:07 AM An unknown intruder attempted to insert a Trojan horse program into the code of the next version of the Linux kernel, stored at a publicly accessible database. Security features of the source-code repository, known as BitKeeper, detected the illicit change within 24 hours, and the public database was shut down, a key developer said Thursday. The public database was used only to provide the latest beta, or test version, of the Linux kernel to users of the Concurrent Versions System (CVS), a program designed to manage source code. The changes, which would have introduced a security flaw to the kernel, never became a part of the Linux code and, thus, were never a threat, said Larry McVoy, founder of software company BitMover and primary architect of the source code database BitKeeper. "This never got close to the development tree," he said. "BitKeeper is really paranoid about integrity, and it turns out that was key to finding this Trojan horse." (Emphasis mine) Linus Torvalds, the original creator of Linux and the lead developer of the kernel, uses BitKeeper to keep track of changes in the core software for the operating system. On a daily basis, the software exports those changes to public and private databases other developers use. An intruder apparently compromised one server earlier, and the attacker used his access to make a small change to one of the source code files, McVoy said. The change created a flaw that could have elevated a person's privileges on any Linux machine that runs a kernel compiled with the modified source code. However, only developers who used that database were affected--and only during a 24-hour period, he added. "The first thing we did was fix the difference," he said. "It took me five minutes to find the change." When BitKeeper exports the source code to other servers, it checks the integrity of every file, matching a digital fingerprint of its official version of the file with the version on the remote machine. That comparison caught the change to the code stored on the server. The changes looked like they were made by another developer, but that programmer said he hadn't submitted them, McVoy said. The recent incident raises questions about the security of open-source development methods, particularly how well a development team can guarantee that any changes are not introducing intentional security flaws. While Microsoft code has had similar problems, closed development is widely considered to be harder to exploit in that way. Linus Torvalds addressed the issue in a post to the Linux kernel mailing list. "A few things do make the current system fairly secure," he stated. "One of them is that if somebody were to actually access the (BitKeeper) trees (software repositories) directly, that would be noticed immediately." A critical security flaw was found in CVS in January, but it's unknown whether the attacker used the vulnerability to gain access to the CVS database. BitKeeper's McVoy hopes the current incident will quash objections raised by some members of the development who don't want to add a new feature that would require all changes to be digitally signed. Even so, he said, the open-source development model likely would have quickly turned up any security flaws. "A Trojan horse is just a bug that a person has put into the system deliberately," he said. "The open-source security model is that everyone is using this stuff, so bugs get found and get fixed. That's one of the reasons that you are not hearing me freak about this." McVoy said the disk from the compromised server has been saved for later analysis, but any decision to contact law enforcement belongs to Torvalds and others. Torvalds could not be immediately reached for comment. http://asia.cnet.com/newstech/security/0,39001150, 39156944,00.htm
nothing like a good kernel vulnerability to bring out all those low UID posters!
-R'
the beginning? as in by hand? my no theenk so...
The strings that such a compiler are looking for aren't C keywords or macros, so the preprocessor won't change anything. Identifiers can't be broken up without breaking the program, so you can't add random white space in the middle of words. Adding random white space in between words has never affected the C family of languages (if it did; there wouldn't be any holy wars over indentation styles, because only one method would work, and we'd all have to use it.)
At some point, an implementation of login(1) has to look at "/etc/shells" and call the user ID resolver routines and drop privs and exec what will probably be one of three or four known shells. If your compiler hack detects "/etc/shells" as a string literal, then proceed to the next test.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
All of the comments listed here are quite rediculous. First off the backdoor was a local privledge escalation vulnerability so if a server is already compromized it could have led to root on such server. Most production web servers/schools/the majority of computers on the net. arnt going to be much of a problem for even a moronic attacker to get root on as the urgency is not really for patch implementation and system admin's at least good ones, arnt going to randomly update something which will take down the box unless they feel it is completely neccessary. Any remote compromise these days and in the past ( excluding certain systems which were properly level'd off/conforming to a higher security model b1 etc) has and should be considered a full compromise of the box. Since the introduced vulnerability is local, this would not lead to mass loads of compromised internet systems, nor as someone here wrote "widespread distribution of cc's across the internet". If it had not been caught it would likely remain undetected until someone randomly found it through a complete and detailed kernel audit. This kind of thing doesnt happen everday, a forumlar of the few people that can actually do a decent auditing job, and the luck of their source choice (wouldnt most of them be searching for remote vulnerabilities anyway ??). The question you should ask yourself is why was this particular vulnerability introduced. Which systems was this guy going after if at all, (If not any systems in particular it was probably done as something holding a certain coolness factor), Which machines on the net have fairly anal local security polocies and employ enough remote access that passwords illbegotten (ssh trojan/keyloggers etc. ) the answer seems to point to shellservers, and hosts used by "underground groups", hacker's boxes, Box's people use to irc and development servers, (silly developers giving everyone access to your systmes). The boxes employed by this group of people are going to probably have several users, and probably be implimenting higher levels of individual security and scrutiny. Does this vulnerability not fit this model perfectly?
Actually thikning out the ramafications and intentions of a persons actions seems to be a foriegn thought in the computer security field, ive heard this breach to be called an act of terrorism, when it seems like nothing more than a prank. Nothing seems to give security people kicks like scaring the general public eh?
- Cid
cid_skid_formersk@yahoo.com