Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

The Linux Backdoor Attempt of 2003

Unknown Lamer posted about a year ago | from the alright-which-one-of-you-did-it dept.

Security 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.'"

Sorry! There are no comments related to the filter you selected.

SHIT HAS HIT THE FAN !! (-1)

Anonymous Coward | about a year ago | (#45082171)

Run for the hills !!

OMG enough (5, Insightful)

Virtucon (127420) | about a year ago | (#45082199)

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 (5, Interesting)

sqorbit (3387991) | about a year ago | (#45082229)

It's just like the "We can't explain this, so it must have been aliens" philosophy. If someone tried to create a backdoor, it must be the NSA. Not some bored hacker or some other explanation.

Re:OMG enough (5, Funny)

Russ1642 (1087959) | about a year ago | (#45082741)

There's a 50% chance it was aliens. Either it was aliens, or it wasn't aliens.

Re:OMG enough (0, Troll)

Squidlips (1206004) | about a year ago | (#45082861)

Aliens as in Chinese, yes. Microsoft was another possible enemy of Linux...

Re:OMG enough (0)

Anonymous Coward | about a year ago | (#45082883)

I'm not saying it was aliens, but...

Aliens

Re:OMG enough (3, Insightful)

Anonymous Coward | about a year ago | (#45082781)

Bored enough to know how to stealthily insert their modified code into the CVS repo.

That eliminates most script kiddies...

Re:OMG enough (3, Insightful)

Anonymous Coward | about a year ago | (#45082283)

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 (1)

Anonymous Coward | about a year ago | (#45082421)

Correction from the parent AC. Records not sold to the Guardian, but handed over.

Re:OMG enough (5, Informative)

djmurdoch (306849) | about a year ago | (#45082419)

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?!?!?

Yes, there was an investigation [indiana.edu] . The name attached to the log entries belonged to someone who said he didn't make the changes.

Re:OMG enough (4, Informative)

Virtucon (127420) | about a year ago | (#45082541)

L. McVoy...

It's not a big deal, we catch stuff like this, but it's annoying to the
CVS users.

My Favorite from A. Walrond..

Somebody getting access to and inserting exploits directly into the linux
source is not something we should take lightly. Whilst we understand the
limits of the problem, the fact that it happened at all could get /.'d out of
all proportion and be used to seriously undermine linux's reputation

Note, back in 2003, "/.'d out of all proportion..." which is exactly what this article is all about.

Re:OMG enough (0)

Anonymous Coward | about a year ago | (#45082771)

It was me.. Sorry.

Re:OMG enough (2)

camperdave (969942) | about a year ago | (#45082819)

It was me.. Sorry.

He's at 0000::0:1. Get him!

Re:OMG enough (3, Insightful)

gstoddart (321705) | about a year ago | (#45082481)

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.

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. ;-)

Re:OMG enough (1)

Virtucon (127420) | about a year ago | (#45082595)

I do listen to the news, so prove to me that it was the NSA rather than some bored college student looking to inject some mayhem? During my first two years of college, I worked as a Systems Operator. We had students who pushed the envelope on APIs, system calls and other things. They'd come up with strange things and bugs and report them to us. "I created this 128 character string and it had somebody's name in it when I printed it out." Well that's what it was like in the late 70s, when memory wasn't cleared out before you started using it. Things like that and high watermarking on disks subsystems didn't just happen because somebody thought of them one night, they came about because they represented exposures. Nowadays it seems that if college students or curious hobbyists try to push the envelope, they're labelled hackers and prosecuted under the CFAA.

Re:OMG enough (1)

Anonymous Coward | about a year ago | (#45082723)

I do listen to the news, so prove to me that it was the NSA rather than some bored college student looking to inject some mayhem?

Proof is hard. I would like to see if there are any hints or evidence even pointing in that direction.

Re:OMG enough (4, Informative)

gstoddart (321705) | about a year ago | (#45082929)

I do listen to the news, so prove to me that it was the NSA rather than some bored college student looking to inject some mayhem?

And why would I seek to prove something to you that it says right in the damned article that nobody knows who did it, or why, or how? I certainly never claimed it was the NSA, and even TFS suggest that, while it could have been the NSA, they don't know.

There is direct proof someone tried to insert a back door, but as far as who did it, nobody fucking knows, and TFS even says that.

Given what the NSA is doing lately, they're a plausible guess, but, there is no proof to suggest what entity did that ... NSA, bored college student, the Chinese, aliens, your mom. It says right in the summary they don't know, and unless someone admits to it, they never will -- but nonetheless, code did magically end up in the code repository they couldn't account for and which they caught. So someone did attempt to insert a back door, that much is fact -- the rest of it is speculation, and that's pretty much evident that it is speculation.

You're asking for proof of something that people are only suggesting as a possibility, not claiming as fact. Which means you're not even debating the article, you're debating something the article didn't say but you're acting as if it did.

You're tilting at windmills there dude.

Re:OMG enough (0)

Anonymous Coward | about a year ago | (#45082533)

You didn't read the article at all you fucking moron. The article mentions there was an investigation.

Re:OMG enough (1)

Virtucon (127420) | about a year ago | (#45082795)

That's hardly an investigation and even if you read what people were writing they all were pretty much "meh." and "That's why we do what we do." Was the FBI brought in? No. Any charges filed? No. Was it distributed in the wild? No. The system they put in place caught the problem before it made it out there. I'm much less worried about this than the other vulnerabilities and possible exposures that are already there and are sold by those nice assholes in France who make it their job to sell this stuff.

You know what's really ridiculous about all of this, this is old news? So if you really want to go back about 10 years ago read this: http://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered [slashdot.org]

Re:OMG enough (1)

Anonymous Coward | about a year ago | (#45082619)

Unless somebody has proof that somebody was trying to create a back door

This code was not inserted through official channels. This makes it at least likely that it was inserted with malicious intent.

It could have been a hacker trying to put that code in.

In which case it would have been a hacker who inserted the backdoor. A backdoor is a backdoor, no matter whether it is installed by the NSA or by a random hacker.

Re:OMG enough (4, Insightful)

Alomex (148003) | about a year ago | (#45082703)

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 (1)

Virtucon (127420) | about a year ago | (#45082875)

Actually in this very specific case the Occam razor's version of event was a malicious attempt.

What's Jodie Foster got to do with this?

Yeah, Yeah, that movie sucked!

Calm down (1)

Anonymous Coward | about a year ago | (#45082735)

Most of the article is about the backdoor, there is one line mentioning NSA that starts with could, it's one possible suspect among many others so stop getting all ultra-defensive.

You might want to look at your own reaction on this. Would you react the same way if it said "could it have been a Chinese attack?" Are you over-reacting because you want everything to be fair or because you're brainwashed by patriotism?

Re:OMG enough (4, Interesting)

ShanghaiBill (739463) | about a year ago | (#45082755)

Unless somebody has proof that somebody was trying to create a back door then stop with all of the "X-Files" shit.

The code snippet is an obvious attempt at a backdoor. What more "proof" do you need?

It could have been a hacker trying to put that code in.

So? How does that make it "not a backdoor"? The code is the same regardless of who put it there.

Some obvious lessons from this are:
1. Run your compiler with the warnings on.
2. Use lint.
Either of these would have flagged this problem.

When run with "gcc -Wall", this warning is produced: warning: suggest parentheses around assignment used as truth value.

Re:OMG enough (1)

girlintraining (1395911) | about a year ago | (#45082853)

Let's just go forward with what we know and stop the speculation

Skip that. How about we go with "Never attribute to malice that which can be explained by stupidity." We're talking about a single character that turns what everyone seems to agree would be an error-check, into an exploit. This sort of thing happens all the time, and nobody says the butler did it, in the observatory, with the lead pipe, when it does. They say "Hey, man, your last diff patch might have a bug." (explains bug) ... a few hours to days later, they reply back with "Oh hey thanks for catching that!"

And assuming this was the NSA is laughable; Have you heard about their latest data center in Ohio? It apparently regularly shorts out in spectacular fashion shooting bolts of lightning between racks of equipment, killing hundreds of thousands of dollars worth of equipment everytime. There's a king sized pissing contest going on as to what the cause is between the NSA, the contractors who built it, and the Army Corp of Engineers, all of whom identify a different cause, or point the finger at a different person. It's a big circle jerk.

Does this sound like the paragon of competence and subtlety to you?

Phew! (0, Offtopic)

cyberpocalypse (2845685) | about a year ago | (#45082219)

while( var = Backdoor() )
{
  fluff goes here
}
else
{
just give em selinux
}

Felten (0)

Anonymous Coward | about a year ago | (#45082227)

"Felten! Felten! Oh Jesus CHRIST, FELTEN!"

Repost (2, Informative)

Anonymous Coward | about a year ago | (#45082251)

This has been posted plenty of times on here, and this article has no new information on the backdoor attempt. About the only thing is the spurious claim the NSA was behind hit. Geez.

Re:Repost (1)

jones_supa (887896) | about a year ago | (#45082347)

Agree. Everyone knows this already.

Re:Repost (5, Funny)

squiggleslash (241428) | about a year ago | (#45082521)

You're forgetting that the NSA is in the news right now, which creates an entirely new angle on it.

I was able to get a copy of the original submission:

Ed Felton writes about an incident, in 2003, in which someone tried to backdoor the Linux kernel, a key component of the GNU/Linux operating system. As you know, Apple just released a new operating system called iOS 6. Is it possible that an NSA contractor, paid in Bitcoins raised through an anonymous Kickstarter project to avoid detection, placed an exploit in the new iPhone 5S? And if so, should the government immediately investigate Google who might have used the feature to implement some sort of tracking bug for people using their iPhones in their Teslas?

Re:Repost (1)

Sarten-X (1102295) | about a year ago | (#45082655)

I can see why the original submission was edited.

No mention of a Raspberry Pi.

Re:Repost (4, Informative)

i kan reed (749298) | about a year ago | (#45082733)

Not just in the news, but documented as having worked with software companies to inject backdoors into software, and hints that they may have specifically solicited Linus to do that with Linux.

Type safety (0, Flamebait)

TechyImmigrant (175943) | about a year ago | (#45082263)

If your language returns a boolean from assignment, then it sucks and invites this sort of thing.

if (a = b) ... should always be an error.

Re:Type safety (1)

piripiri (1476949) | about a year ago | (#45082333)

Wrap assignment in parenthesis to explicitly indicate intended behavior.
if ((a = b)) ...

Re:Type safety (-1, Troll)

slashmydots (2189826) | about a year ago | (#45082335)

That is exactly what I was thinking. What backwards language/compiler are they using? Obviously nothing from this decade.

Re:Type safety (1, Insightful)

ninlilizi (2759613) | about a year ago | (#45082599)

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:Type safety (1)

ggraham412 (1492023) | about a year ago | (#45082369)

Good point. Technically thought, the assignment doesn't return a boolean, it returns a number.

The "if" statement on the other hand treats integer arguments as implicit booleans: if (a != 0) ... that's where the type unsafety lies.

Re:Type safety (1)

fisted (2295862) | about a year ago | (#45082451)

It should be an error in toy languages, yeah.
In C, not so much.

FWIW, assignment doesn't ``return a bool'' but ``is an expression which evaluates to the assigned-to value (an rvalue of appropriate type).''

Re:Type safety (1)

mrchaotica (681592) | about a year ago | (#45082665)

But even in C, it should (and does using any reasonable compiler, I think) generate a warning.

Personally, I try to code any comparisons involving literals with the literal on the left (e.g. if(0 == foo)... instead of if(foo == 0)...) so that I get a "lvalue required as left operand of assignment" error if I leave one of the equals signs out. And when I intend an assignment, I do it in a separate statement (e.g. foo = 0; if(0 == foo)...).

On a side note, the compiler folks probably ought to change that error message to "hey idiot, you're doing an assignment when you really mean to do a compare" since that's more likely to be the cause rather than that you intended to assign but just forgot that your identifier wasn't a valid lvalue.

Re:Type safety (1)

Kaenneth (82978) | about a year ago | (#45082485)

I, personally don't like 'root' being user number zero.

When I first started using Linux I tried to run a process under a service account by name 'dvrservice'. What actually happened was the process launcher parsed the name 'dvrservice' into an integer, value 0, thereby running the public facing network service as root.

fortunently I detected that before anything bad happend.

It would be more secure, I think, if each install generated a random uid for root, so that instead of (uid = 0) or obfuscated (uid = serviceuid - serviceuid), etc. programs would have to call (uid = getroot()) so that a search/flag for all occurances of that function call could find everything trying to run as root.

But I have no delusions that this change could be reasonably made across Linux at this time, it's not like changing a HOSTS file.

Re:Type safety (1)

lesincompetent (2836253) | about a year ago | (#45082575)

That would be a nightmare in many ways IMHO.
I think it should be a standard constant value, just not 0. Something more unique and immediately distinguishable.

Re:Type safety (1)

Kaenneth (82978) | about a year ago | (#45082641)

5318008?

I don't know how many bits a Linux UID is, I think Windows uses GUIDs (128 bits; but not all unique iirc) so I don't know the odds of a collision, but yeah, it would be a problem if you org assigned standard numbers to service accounts or something...

But if you never referred to accounts by number, only name, and left the numbers to the internal systems...

oh, maybe drive the fundies crazy, UID 666.

I read a booklet at my religious aunts house once that claimed the existance of chmod 666 as part of the proof that computers were going to implement the 'number of the beast'...

Re:Type safety (1)

lesincompetent (2836253) | about a year ago | (#45082811)

PLEASE scan that booklet! It'll go viral overnight!

Re:Type safety (1)

TechyImmigrant (175943) | about a year ago | (#45082725)

That would be a neat attack vector.

user = 'low_priority_user'

Parsed as root, reads like not root.

Re:Type safety (0)

Anonymous Coward | about a year ago | (#45082519)

If this sort of thing bothers you, maybe you shouldn't be using big-boy languages.

Re:Type safety (1)

TechyImmigrant (175943) | about a year ago | (#45082739)

It doesn't bother me. It bothers all the undisciplined programmers. I program in gates, where everything is a bool.

Re:Type safety (0)

Anonymous Coward | about a year ago | (#45082697)

If your language returns a boolean from assignment, then it sucks and invites this sort of thing.

That assignment didn't return a boolean. In C, everything that is 0 (an integer 0, a null pointer, the NUL character) is interpreted as "false", and everything else as "true".

Re:Type safety (1)

TechyImmigrant (175943) | about a year ago | (#45082825)

I know how C works. C is incompatible with a large swath of humans. Particularly when it comes to malicious obfuscated code.
 

For the one you catch, how many do you overlook? (1)

Anonymous Coward | about a year ago | (#45082267)

Each of us has between 10 and 10,000 different code lineages in operation on our desktop.

= in an if statement should end in warning/error (2)

oo_00 (2595337) | about a year ago | (#45082285)

Single = in an if statement should end in warning and should be considered error in production code. There should be compiler --switch for this.

Re:= in an if statement should end in warning/erro (0)

Anonymous Coward | about a year ago | (#45082433)

Python does this at all times. The assignment operator is just plain invalid within an "if" conditional.

Re:= in an if statement should end in warning/erro (1)

AuMatar (183847) | about a year ago | (#45082483)

Most compilers do make this at least a warning. It isn't an error because it's a moderately common C-ism to do this in order to assign and check the return value or a function in 1 statement. Particularly if the value is a standard 0 on error or NULL on error return.

Re:= in an if statement should end in warning/erro (0)

dfghjk (711126) | about a year ago | (#45082555)

No, it shouldn't.

Re:= in an if statement should end in warning/erro (0)

Anonymous Coward | about a year ago | (#45082729)

look at this wrong opinion right here.

look at it.

Re:= in an if statement should end in warning/erro (1)

0123456 (636235) | about a year ago | (#45082871)

No, it shouldn't.

It likely should be an error if you're setting it to a constant. That's equivalent to forcing true or false in the if, with a side-effect of changing the value of a variable. I can only see a few very convoluted cases where that would make any sense, and there are far more readable ways to write them.

The old 'if (fp = fopen("foo", "r") )' makes sense, but there's no real reason to write it that way any more. It should at least be a warning.

Re:= in an if statement should end in warning/erro (2)

Waffle Iron (339739) | about a year ago | (#45082683)

I always use '-Wall -pedantic' for gcc, and if my code is producing any warnings, I always fix them all.

If the kernel developers had been doing this, they would have seen a big fat warning. For those who still like to use this dubious idiom, putting double parentheses around the assignment make the side effects more explicit to the reader and disables the warning.

Re:= in an if statement should end in warning/erro (1)

Impy the Impiuos Imp (442658) | about a year ago | (#45082881)

99.99% of programmers don't need to use single = in a conditional, so add a compiler switch to disallow it as a syntax error instead of just a warning.

Given modern optimizing compilers designed hand-in-hand with chips, probably 99.99999%. Like 3 guys maybe.

C/C++ operator = (5, Interesting)

Jamu (852752) | about a year ago | (#45082287)

It's why placing constants on the left of the equality operator is a good idea in C/C++. The whole line then looks suspicious because its constants are on the right, and the first thing you'll think about is bugs involving operator = instead of operator ==. Unfortunately there's a lot of old code that doesn't do this, but it's easy enough for a compiler to issue warnings about operator = in if-statements.

Re:C/C++ operator = (1)

tuffy (10202) | about a year ago | (#45082455)

I believe many of them do offer that as a warning, since something like:

if (var = NULL) {/*error*/}

isn't what anybody wants, whereas mixing assignment and conditionals may make sense in other contexts, like:

if (NULL == (var = func())) {/*error, var is NULL*/}

Re:C/C++ operator = (0)

Anonymous Coward | about a year ago | (#45082525)

If you can't distinguish = from ==, then use an editor that turns one of them red, bold, and blinking. Don't write code that breaks centuries of mathematical convention assuming other people need your "help".

Re:C/C++ operator = (1)

Anonymous Coward | about a year ago | (#45082779)

The centuries of mathematical convention say that "=" is equality comparison (as in "2+2=4"). It is C which breaks that centuries-old convention.

Re:C/C++ operator = (0)

Anonymous Coward | about a year ago | (#45082549)

Also known as 'Yoda conditions' https://en.wikipedia.org/wiki/Yoda_conditions

I practice them a lot, actually, for improved readability in quite a few cases. Though as 'anti-sloppiness habit' i disagree on the desirability.

Re:C/C++ operator = (-1)

Anonymous Coward | about a year ago | (#45082649)

1) No, it's not. It's a false sense of security.
2) There is no such thing as C/C++.

Re:C/C++ operator = (3, Interesting)

TheCarp (96830) | about a year ago | (#45082669)

OMG Thank you.

I have often seen this form, not just in C but elsewhere. I always thought it was more a formatting preference for readability (often the variables being tested part of the equation doesn't change, so move the part that does change closer towards the start of the line)

I never considered that it might help catch or mitigate this sort of error. Truely 0 = uid, while also quite bad yet legal C*, doesn't reassign the UID.

* I always thought this was legal, but now that I try it, I find this gives a compile time error - "error: lvalue required as left operand of assignment". Currently gcc is the only compiler I have on hand, so i can't check some of the much older ones.

Re:C/C++ operator = (0)

Anonymous Coward | about a year ago | (#45082691)

You're kind of an idiot, aren't you?

NSA (Probably) installed one Anyway (0)

ObsessiveMathsFreak (773371) | about a year ago | (#45082309)

Article overlooks the other big backdoor which was installed in 2003: SELinux [wikipedia.org] .

I still have no idea why my kernel would need an internal firewall, but I do know why the NSA would want to install one in mine and everyone elses'. Exactly how many more NSA scandals do we require before this "feature" is rolled back?

Re:NSA (Probably) installed one Anyway (0)

Anonymous Coward | about a year ago | (#45082785)

Oh christ....if you don't understand why you'd need Mandatory Access Controls in some situations, there simply is no point in explaining to you.

Re:NSA (Probably) installed one Anyway (1)

Anonymous Coward | about a year ago | (#45082857)

That's the most useless reply ever. "If you can't figure it out yourself, I'm certainly not going to tell you!"

Sounds like you don't know the answer either, but just don't want to admit it.

This is the reality, no need for tinfoil hats (2, Informative)

Anonymous Coward | about a year ago | (#45082311)

The difference between linux and closed source OSs is that on linux you may be able to identify malicious code in the kernel and remedy this situation. For closed source solutions you're truly fucked through and through. You seriously think Microsoft and Apple haven't backdoored their OS ? Just one more reason to stop using closed source software if you value your privacy, your secrets etc...

Re:This is the reality, no need for tinfoil hats (0)

Anonymous Coward | about a year ago | (#45082459)

wait...a failed open source backdoor is one more reason to not use closed source? that doesnt logically follow.

Re: This is the reality, no need for tinfoil hats (0)

Anonymous Coward | about a year ago | (#45082653)

A "discovered" attempt is another reason to continue to use (and inspect) Open Source. You'll never discover the closed source back doors (though they will discover you).

Re:This is the reality, no need for tinfoil hats (0)

Anonymous Coward | about a year ago | (#45082705)

The key word there is 'failed', coupled with the assumption 'such a thing has occurred and NOT failed for Apple, Microsoft'.

Re:This is the reality, no need for tinfoil hats (0)

Anonymous Coward | about a year ago | (#45082581)

Linux isn't an OS, it's a kernel.

Wow (1)

ggraham412 (1492023) | about a year ago | (#45082319)

I am impressed that the kernel team caught that. Kudos!

I did it. (2, Funny)

cellocgw (617879) | about a year ago | (#45082321)

Signed,
Spartacus

Re:I did it. (0)

Anonymous Coward | about a year ago | (#45082479)

No, I broke the dam.

How did this happen? (0)

slashmydots (2189826) | about a year ago | (#45082325)

I'm not familiar with how Linux coding goes but how does code show up that nobody knows who wrote it? There's no IP tracking or user accounts or logins or an e-mail account or anything? People can just throw nonsense out there anonymously and maybe it'll get included? Or did they bypass the normal submission means and somehow just sneak it into an about to be built code block?

Re:How did this happen? (1)

Anonymous Coward | about a year ago | (#45082383)

Further investigation determined that someone had apparently broken in electronically to the CVS server and inserted a small change
It was in the description.

Re:How did this happen? (1)

Anonymous Coward | about a year ago | (#45082393)

Give me an R!
Give me a T!
Give me an F!
Give me an A!

Re:How did this happen? (1)

gstoddart (321705) | about a year ago | (#45082545)

Or did they bypass the normal submission means and somehow just sneak it into an about to be built code block?

Well, did you even read the entire summary? Where it says that pretty much everything was bypassed?

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

Getting code into a versioning system without a record of it means you bypassed the whole thing, or the versioning system was crap.

Eleven years (0)

Anonymous Coward | about a year ago | (#45082341)

Slashdot has sucked for ELEVEN YEARS.

http://lkml.indiana.edu/hypermail/linux/kernel/0210.1/1978.html [indiana.edu]

a lot of hot air, slashdot fodder and a troll

Re:Eleven years (0)

Anonymous Coward | about a year ago | (#45082629)

LOL! Stallman is such a pathetic loser. I saw him eat some skin off his foot one time. In front of a huge audience. It's on youtube.

slashdot: old news that nerds cared about... (0)

Anonymous Coward | about a year ago | (#45082373)

10 years ago...this isn't new news. It could have been Larry McVoy himself, for all we know, he had motivation to see CVS die a painful death, no?

Too easy to shoot yourself on the foot (1)

jones_supa (887896) | about a year ago | (#45082391)

I guess compilers are already smart enough to warn about this kind of accident, but sometimes I still wonder if it would have been better to have := for assignment and = for comparison also in C.

Re:Too easy to shoot yourself on the foot (0)

Anonymous Coward | about a year ago | (#45082491)

I guess compilers are already smart enough to warn about this kind of accident, but sometimes I still wonder if it would have been better to have := for assignment and = for comparison also in C.

That's why seasoned programmers would write the constant to the left of the operator (0 == current->uid).

Re:Too easy to shoot yourself on the foot (0)

Anonymous Coward | about a year ago | (#45082777)

No, "seasoned" programmers don't do that. Idiots do.

The other tipoff (0)

Anonymous Coward | about a year ago | (#45082413)

-Wno-parentheses switch added to the "EXTRA_CFLAGS" in the makefile

Do not attribute to malice... (0)

Anonymous Coward | about a year ago | (#45082427)

...what can be adequately explained by stupidity.

That was then, this is now (-1)

Anonymous Coward | about a year ago | (#45082527)

Back then having both Bitkeeper and CVS source code repositories and noticing the differences between the two exposed an attempt to place a backdoor in the Linux kernel.

Now we have only a single Git repository but we are still safe because nobody can figure out exactly how to commit and/or merge and/or squash merger and/or push and/or rebase.

Re:That was then, this is now (0)

Anonymous Coward | about a year ago | (#45082749)

here [youtube.com] No need to thank me.

I hope they monitor integrity more carefully (1)

guanxi (216397) | about a year ago | (#45082551)

I hope the Linux team, which has the security of billions of people in their hands, uses far better security than Felton's article implies. (And for all I know it is.)

The excerpt above suggests that someone happened to notice a change that wasn't pointing to an approval record. What if nobody happened to notice? What if the attacker also created an approval record? And was there a serious effort to find the exploit used and close it, and find the perpetrator?

I hope the Linux kernel's integrity is monitored much more carefully. For example (and I'm just guessing; I don't know much about the Linux kernel), someone could manually validate that every change to the code's fingerprint (and/or the compiled kernel's fingerprint) is legitimate. At ~200 changes/day, one person could do it -- a small investment for something so critical.

The widespread use of Linux makes it an exceptionally valuable target. People will spend a lot of time and money attacking it. It's security needs to be proportional to the threats.

Repost (5, Insightful)

jovius (974690) | about a year ago | (#45082567)

Re:Repost (2, Insightful)

Anonymous Coward | about a year ago | (#45082829)

Why didn't /. just hold off another month and repost it exactly a decade after it was really news.

Re:Repost (1)

neo-mkrey (948389) | about a year ago | (#45082889)

Good find (or a great memory). Either way, well done. I wish I had mod points to give today.

Compiler warning (3, Interesting)

JDG1980 (2438906) | about a year ago | (#45082591)

Doesn't GCC warn for this by default? I'm pretty sure I remember getting compiler warnings from it in cases when I deliberately had an assignment operator in an if conditional.

SubjectsInCommentsAreStupid (2)

lesincompetent (2836253) | about a year ago | (#45082597)

It's FOIA time!

== stupid language construct. (0)

Anonymous Coward | about a year ago | (#45082843)

This wouldn't have happened if they had written it in Basic.

Witch Hunters and good laughs (0)

Anonymous Coward | about a year ago | (#45082863)

Or perhaps it was the KGB? Or Nazi's hiding out in South America?

OR PERHAPS..... ALIENS FROM OUTER SPACE!!!!

Well, since we're in the mood of publishing rubbish ideas with ZERO evidence I vote for aliens!

CVS exploit (0)

Anonymous Coward | about a year ago | (#45082921)

various repos, such as cvs.openbsd.org ware owned using the same bug few months before that. all kinds of fun were had.

that is until one fucktard leaked the code to kiddies who had no idea of hacker ethics, that is to stay under the radar at all costs (or just troll theo, because his hacker ethics won't allow to public admit he has been owned).

this eventually killed the cvs bug, and, together with the same sad fate of rsync bug, made the "trust no-one with your warez" rule set in stone.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?