The Linux Backdoor Attempt of 2003 360
Hugh Pickens DOT Com writes "Ed Felton writes about an incident, in 2003, in which someone tried to backdoor the Linux kernel. Back in 2003 Linux used BitKeeper to store the master copy of the Linux source code. If a developer wanted to propose a modification to the Linux code, they would submit their proposed change, and it would go through an organized approval process to decide whether the change would be accepted into the master code. But some people didn't like BitKeeper, so a second copy of the source code was kept in CVS. On November 5, 2003, Larry McAvoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all. Further investigation determined that someone had apparently broken in electronically to the CVS server and inserted a small change to wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' A casual reading makes it look like innocuous error-checking code, but a careful reader would notice that, near the end of the first line, it said '= 0' rather than '== 0' so the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid. In other words it's a classic backdoor. We don't know who it was that made the attempt—and we probably never will. But the attempt didn't work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. 'Could this have been an NSA attack? Maybe. But there were many others who had the skill and motivation to carry out this attack,' writes Felton. 'Unless somebody confesses, or a smoking-gun document turns up, we'll never know.'"
OMG enough (Score:5, Insightful)
Unless somebody has proof that somebody was trying to create a back door then stop with all of the "X-Files" shit. It could have been a hacker trying to put that code in. How was the system that hosted the CVS repository managed? Was it hacked? Was there any investigation or was it possibly somebody that did something stupid and now everybody thinks it's somehow tied to the NSA?!?!?
Let's just go forward with what we know and stop the speculation, that is unless somebody has some hard facts like an IP address that belongs to the government or a chain of evidence.
Re:OMG enough (Score:3, Insightful)
In 2003, there wasn't even near the IDS/IPS technology of today. Firewalls were in place, but some places still have not moved to internal segments with firewalls on the internal networks.
This could have been anyone. Yes, it -could- have been the Greys, the NSA, the CIA, MI5, Elbonia's secret police, or the Illuminati, but right now, it was a detected hack attempt, and anything more is pure rumor unless there is something definitely specified in the papers Snowden sold to the Guardian.
Re:OMG enough (Score:4, Insightful)
Which is pretty much the same thing, isn't it?
'Somebody' or 'a hacker' or 'an unnamed government agency' .. somehow, code got inserted into a repository with no audit trail and no record.
That the NSA has been motivated to do stuff like this is readily apparent unless you've not listened to any news in the last several months. Whether they did it or someone else did, who knows.
But it's hardly a wacky assertion that it could have been the NSA. It also could have been me, but I'm not telling. ;-)
Repost (Score:5, Insightful)
http://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered [slashdot.org]
Re:Type safety (Score:1, Insightful)
A language and compiler from last decade.
A golden age when only the observant few knew without a doubt that the worlds governments were malignant.
And everybody else thought they were just paranoid loons overdue their Thorazine shots.
Re:OMG enough (Score:5, Insightful)
Actually in this very specific case the Occam razor's version of event was a malicious attempt.
Just the other day I arrived at work to find traces of my externally accessible office door being jimmied. Now what is more likely (1) that the janitors lost the master key and forced their way in to vacuum clean or (2) that someone (likely a petty burglar) opened it and took my missing radio?
There is a suid exploit inserted in an unauthorized way. The simplest explanation is a backdoor attack. The subsequent investigation seems to support this further, even though we still do not know with certainty since the guilty person was never caught. However we can operate on the assumption that this was a malicious attack and discuss it as such.
Re:OMG enough (Score:3, Insightful)
Bored enough to know how to stealthily insert their modified code into the CVS repo.
That eliminates most script kiddies...
Re:Repost (Score:2, Insightful)
Why didn't /. just hold off another month and repost it exactly a decade after it was really news.
Re:OMG enough (Score:5, Insightful)
> The code snippet is an obvious attempt at a backdoor. What more "proof" do you need?
Actually, the code snippet, without context is not an obvious attempt. It is a cleverly hidden attempt that COULD be a genuine error.
However, having no approved submission to track it back to, that makes it an obvious attempt, even more so with evidence that the hosting system was compromised.
I would even call it obvious if they had an approved submission if the submitter didn't have some good justification for mucking with an error handler for a case that shouldn't happen, those tend to not need much maintenance.
Re:C/C++ operator = (Score:5, Insightful)
"Unfortunately there's a lot of old code that doesn't do this..."
Nice implication that this is a standard rather than a preference. A lot of new code "doesn't do this" either because a lot of people don't feel like you do, myself included.
Writing expressions backwards hampers the readability of code and only theoretically catches problems. I can count on one hand the times in my career I've suffered this particular fate and I'm not going to pay a price every day for a structural "solution" to a problem I don't have. I've been working with programmers that do this for 20 years and have never found it to be anything but a nuisance. If it works for them, fine, but it doesn't go into my work. I'm not weak but if you are then by all means, use your crutch.
Sometimes the answer is be better at what you do. Once upon a time you could declare a local variable in a switch statement without explicitly limiting scope. Now you must incur the wrath of the nanny compiler or pollute your code with compiler-pacifying turds. This could be made to work right but the same people who think we need shit like this can't be bothered doing a proper job of implementing it. We have attitudes such as yours to thank for crap like that.
At my new job there are debates on what compiler warming levels to adopt. The reason is the release process enforces a no-tolerance policy for warnings and there's a large code base that will never be warning-free at higher levels. This is what you get when you create compiler-enforced "rules" rather than focus on skills and better code quality, particularly when you abdicate to tools you don't control or even understand.
Re:I hope they monitor integrity more carefully (Score:5, Insightful)
It is monitored more carefully. Notice that the backdoor was only introduced into the CVS copy, which wasn't the official copy used to create kernel releases. It never made it into the official copy in BitKeeper, because to get there it would've had to go through the official review and approval process that would've caught and rejected it. And without making it into the BitKeeper repository it never would've been used by any major distribution, only by developers and private distributions that pulled from the CVS copy because of objections to BitKeeper.
And today even that unofficial copy is gone. With the change to git I believe there aren't any secondary copies in other version-control systems except maybe private ones developers keep for whatever reason which wouldn't be able to feed changes back into the main repository without going through the review and approval process every submission has to go through.
Long and short, the Linux kernel repository's no more vulnerable than the internal repositories for Windows or the Oracle database system, and it's probably less vulnerable. Microsoft or Oracle's repositories will take commits from any random contractor that's been hired to work on the code, regardless of their background or history. The Linux repository... it may accept submissions from anyone, but the degree of review before approving the submission depends heavily on how well the project maintainers know the submitter. The first submissions from someone the maintainer doesn't know are going to be reviewed with a fine-toothed comb and a skeptical eye, and very few black-hats are going to be willing to spend years submitting high-quality code to build up enough of a reputation with the maintainer to be able to get code in with only a cursory review. It's the difference between a development team and a developer community.
Re:OMG enough (Score:5, Insightful)
In the absence of evidence, I would be more likely to refrain from naming anybody.
Some unknown actor did it, how and for what reasons is completely unknown. Had it worked it would have resulted in a backdoor.
Listing shady entities it could have been might be a fun game, but it's meaningless. And TFS pretty much says that.
Re:Type safety (Score:5, Insightful)
Here's why the UID is 0 and should stay 0.
In most assembly languages, when you compare against a value, you have use a "compare" instruction that effectively does a subtraction, but throws away the result.
In most CPUs, there is a flags register with a zero (Z) bit, which is flipped whenever a value is loaded that is zero.
When you want to see if something like your accumulator or another register is an arbitrary value like 100, you need to do a "compare 100" and then "branch if equal to whatever..."
If it's zero, you can just load the value and skip the compare step. You get a "free compare" when the value you want to compare against is zero.
So if the superuser is not zero, there will be a performance penalty.
Besides, this dumb shit is C's fault for using = and == as operators. Pascal had it right with := being the assignment operator.
Wait, this happened in 2003? (Score:3, Insightful)
But of course, they weren't behind it! They couldn't have done it!
Re:OMG enough (Score:3, Insightful)
There is direct proof someone tried to insert a back door,
Or there was a coding error. After all, one single missing "=" makes its effect that of a back door, even if that had not been the intent.
One wonders just how many of this type of "back door" actually exists in the mountain of source code.
The unique thing about this incident is that it was only found by some random diff, not someone reading validly submitted code and saying "oh wait this is a back door".
Given all the massive patches and totally new sections of code that get submitted each year, its apparent that the code in the kernel is trusted because of where/who it comes from, not necessarily that every single line of it is "correct" or doing what it seems to be doing.
Re:C/C++ operator = (Score:3, Insightful)
In hindsight this is one of the things that I wish Kernighan & Ritchie (the original authors of C) should have considered.
Pascal and Ada both use ":=" as an assignment operation and "=" for testing equality, so this type of error is a non-issue in these languages. Furthermore Pascal (1970) actually predates C (1972) by two years, so it bears consideration why K&R overlooked this possibility.
That said, nearly all modern compilers (incl. GCC) do print a warning if you use a "=" operation in a if() or while() condition without explicitly surrounding the expression in parentheses - but then you have to be willing to examine the warnings output (as you'll still get your executable in the end), unless you're disciplined enough to use compiler flags like -pedantic -Werror as a means of extra quality assurance.
I think the ISO C standards body should consider introducing ":=" as an alternate assignment operator in a future standard of C, and then all compilers could offer a switch that'd forbid the use of "=" for when you're writing new C code from scratch for new projects.
You'd then still have the problem of existing codebases needing maintenance still being at risk of misuse of "=", but eventually if such a newer C standard started to enjoy widespread support, people could then do a search-and replace for uses of "=" with ":=" in existing code. (I say this with a bit of pessimism since Microsoft's C/C++ compiler still doesn't support C99 fully).
Re: OMG enough (Score:5, Insightful)
The fact that
strongly suggest that this was a deliberate feature, and not a casual error. I've done a lot of security audits of mission critical systems in my time and I've seen a lot of potentially catastrophic casual errors. You can always see what (innocent) thing the programmer intended to do. There's no 'innocent' thing this change could do. This is intended.
Who intended it? That's another question.
Re: This is the reality, no need for tinfoil hats (Score:2, Insightful)
Some one with knowledge of the code discovered a bug in the code. That happens for closed source as well. Most people who use open source don't look at the code so it's essentially closed source.