The Linux Backdoor Attempt of 2003

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

Comments

OMG enough

[Virtucon]

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

[sqorbit]

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

[Anonymous Coward]

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

[djmurdoch]

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. The name attached to the log entries belonged to someone who said he didn't make the changes.

Re: OMG enough

[Anonymous Coward]

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

Re:OMG enough

[gstoddart]

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

[Anonymous Coward]

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

Re:OMG enough

[Virtucon]

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

[Virtucon]

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

[Anonymous Coward]

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

[Alomex]

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

[Anonymous Coward]

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

[Russ1642]

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

Re:OMG enough

[ShanghaiBill]

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

[Anonymous Coward]

It was me.. Sorry.

Re:OMG enough

[Anonymous Coward]

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

That eliminates most script kiddies...

Re:OMG enough

[Virtucon]

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

Re:OMG enough

[camperdave]

It was me.. Sorry.

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

Re:OMG enough

[Lothsahn]

Yeah, and then Xavier Bestel says:
Eh .. way too late :)

http://slashdot.org/article.pl?sid=03/11/06/058249&mode=thread&tid=106&tid=185&threshold=4


/. Dupe!

Re:OMG enough

[girlintraining]

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?

Re:OMG enough

[Squidlips]

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

Re:OMG enough

[Virtucon]

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!

Re:OMG enough

[Anonymous Coward]

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

Aliens

Re:OMG enough

[gstoddart]

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

[Anonymous Coward]

It's amazing, but your logic is sound.

Re:OMG enough

[sl4shd0rk]

then stop with all of the "X-Files" shit.

What if I told you all of the "X-Files" shit comes quite close to actual recent events.

Re:OMG enough

[VortexCortex]

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

You've identified yourself as a threat to National Security. For us to analyze your dedication to your country, you must now become an intern for the NSA.

Please report to the #6 concent-- Er... Internment camp for further instructions. Transportation will be provided via flashy car at your option.

Re:OMG enough

[Anonymous Coward]

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!

Do you know what else sucks?

Gravity!

Re:OMG enough

[wagnerrp]

I think what Virtucon was trying to complain about, but failed miserably in conveying, was not the claim that someone was trying to insert a backdoor into the Linux kernel, but that that someone was the NSA, as there is zero evidence to point to any suspect.

Re:OMG enough

[Attila Dimedici]

Except that clearly SOMEONE was trying to create a backdoor. That someone may not have been a government agency, in fact the summary seems pretty clear to me that they are not saying that it WAS a government agency. The summary clearly states that there is currently no way to know who put the backdoor code into the kernel repository.

A backdoor is not necessarily something put in to allow a government agency to access a system. The term "backdoor" refers to any code which intentionally allows an unauthorized user of the system to access the system (there are probably a few cases where something was considered a "backdoor" that was not intentionally written for that purpose, but generally, such code only comes about when someone does it on purpose).

Re:OMG enough

[stanlyb]

Under normal circumstances, you are right. But keeping in mind all the leaks, and all the multi-billion data centers, which no one but the government is using....kinda of changes everything.

Re:OMG enough

[Hadlock]

I would probably be more apt to name the Chinese or the Russians before the NSA, after all, the Chinese have a decent financial stake in linux development, and have had for some time. Red Flag Linux (est. Jan 2000) has it's roots in Chinese state-funded computer science.

Re:OMG enough

[TheCarp]

> 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:OMG enough

[Dunbal]

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

Yes. Never try to think that anyone would be interested in compromising a very popular OS. Always assume that it was just a simple mistake, and the fact that safety precautions to avoid this kind of mistake were also bypassed: it's always co-incidence. Never suspect anyone, ever. Security by hiding your head in the sand is the best security ever. By the time you realize they chopped your head off, you're already dead, so you have never have anything to worry about.

After all, what possible kind of advantage would a backdoor like this offer to anyone, anyway? It's not like half the governments of the world are actively trying to break into all the private and public computer networks they can, right?

Re:OMG enough

[Anonymous Coward]

+100 Insightful! This was clearly the work of an experienced kernel hacker.

Re:OMG enough

[gstoddart]

was not the claim that someone was trying to insert a backdoor into the Linux kernel, but that that someone was the NSA, as there is zero evidence to point to any suspect

Except nobody is saying "it was the NSA".

In fact, the last sentence of TFS says

Bould 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.'

Which means all arguments which follow from the claim someone is asserting it was the NSA are horseshit, and have nothing to do with the article. Because the article isn't claiming it was the NSA, and bitching about conclusions the article didn't make are pointless.

Have you stopped beating your wife?

Re:OMG enough

[Anonymous Coward]

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

Yes, that's what would have happen normally.

But this patch was inject directly in the CVS repository, not via the BitKeeper repository.
It hadn't been approved by anyone.
The ChangeLog pointed to someone who says he didn't do it.

This is NOT something that happens all the time. It was much more than just "a single character..."-stuff.

Re:OMG enough

[Anonymous Coward]

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

If I had mod points
And a login

Re:OMG enough

[gstoddart]

I would probably be more apt to name the

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:OMG enough

[Anonymous Coward]

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.

so far so good. but stepping back a bit. what legitimate reason would there be for wait4 to take invalid flags only if the uid is 0?

this is clearly a back door.

Re:OMG enough

[Anonymous Coward]

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

In 2003 as well?

Re: OMG enough

[Pino Grigio]

The question you need to ask yourself is what he sold to the Russians. Presumably he'll keep that a secret.

Re:OMG enough

[Anonymous Coward]

Yeah, and all those people shout "I didn't do nothin'!" while being arrested after being chased on "Cops" are innocent and should be let go.

Re:OMG enough

[mlwmohawk]

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

It was put in surreptitiously, is that not enough to conclude it was intentional? Its one thing to be a skeptic, but it is quite another to ignore facts.

Re:OMG enough

[Anonymous Coward]

A backdoor in the Linux kernel wouldn't benefit the Chinese, Russians, the US, or anyone, especially one that was along this scale (a coding mistake that heuristic security checkers can find.)

The US needs Linux to work since it is the foundation of a lot of embedded devices. Russia and China need Linux to work unless they want to completely reinvent the wheel with their own OS, or completely embrace Microsoft from the watches to the mainframes.

Of course, besides a college student that is bored, a criminal organization would get the most benefit until the hole was found and fixed.

Re:OMG enough

[Anonymous Coward]

Um, the assignment does have parentheses around it, which silences GCC's complaint.

Here's minimal code to wrap around that line. It does not generate a warning on GCC 4.2 or 4.6:

#define __WCLONE 0x10
#define __WALL 0x20
 
#include <stdlib.h>
 
struct procinfo {
    int uid;
};
 
int main(void) {
    struct procinfo * current = malloc(sizeof(struct procinfo));
    int options = 0x30;
 
    if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) {
/* won't be ever reached since 0 is false
        * but calling process gains root
        */
    }
    free(current);
    return 0;
}

Re:OMG enough

[wagnerrp]

I didn't make the original post, nor do I agree with it, for the same reasons you outlined. I'm just informing Alomex he misunderstood Virtucon's post. I'm just the messenger, as it were, apparently shot while beating his wife.

Re:OMG enough

[icebike]

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:OMG enough

[Anonymous Coward]

And of course, Jeremiah Cornelius questions whether it was the NSA, CIA or MOSSAD that did it way back then when only conspiracy theroists and tinfoil hatters would ever suggest such a thing.

Re:OMG enough

[gstoddart]

Or there was a coding error.

A coding error, which got into CVS and bypassed BitKeeper, for which there's no commit logs to account for it? And which by sheer fluke would also have been an exploit?

Sure, it could have been a coding error, but the description of how they found it and what they couldn't subsequently find would strongly suggest that this got in there by some really, er, 'unusual' mechanism.

It sounds like they did the forensics at the time, and that it didn't come in through any mechanism any of them could account for.

If I understood correctly, this didn't get into CVS from a commit, it just ended up in there. And in many years of working with CVS, I'm pretty sure I've never seen that happen.

Re: OMG enough

[Anonymous Coward]

I would speculate that interviews are not done without payments.

Re:OMG enough

[David_Hart]

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

Yes. Never try to think that anyone would be interested in compromising a very popular OS.

Um... Very popular OS? in 2003?

I guess it all depends on your point-of-view. LINUX wasn't all that popular in 2003, just a hobbyist OS.... It has become more popular since.

Re:OMG enough

[HiThere]

If I understood correctly, it came in with a name attached as the modifier, but the owner of the name denied making the change. Sounds like *something* nefarious to me, even if nobody knows who did it.

Re:OMG enough

[icebike]

If I understood correctly, this didn't get into CVS from a commit, it just ended up in there. And in many years of working with CVS, I'm pretty sure I've never seen that happen.

Well, thanks for making my point for me.

Clearly there is a lot of other "back doors" lurking in the wild, presumably in fully blessed and approved code, such as CVS code, and (I speculate) also in the Kernel.

I don't use CVS, but I would have expected that module not to pass the simplest of hash checking if someone simply reached around CVS into the file system, and inserted a line of code.

My point about it being a coding error was merely to suggest it is at least as likely as it being the work of the NSA or aliens.

Re:OMG enough

[Brian Feldman]

Revision control systems are not magic; if you edit the repository, you've changed the data. If they're open source like CVS then there's not a hint of obstacle in writing a program to modify the revision control repository, including modifying any metadata like checksums.

Re:OMG enough

[Anonymous Coward]

Geez girl, your own level of competence is abysmal.

The data center is in Utah, not Ohio. It does not "shoot bolts of lightning between racks of equipment" (that would take hundreds of kilovolts; what it does do is minor arcing).

But in the spirit of your post, I'll assume you were just being stupid rather than deliberately lying.

Re:OMG enough

[Anonymous Coward]

Do you have proof that it was or wasn't a party in question? All you're doing is whining about a discussion that you're not obligated to partake of.

Do yourself a favor, shut the hell up and leave the room. You're a waste of space.

Re:OMG enough

[Anonymous Coward]

Linux was a popular server OS even in 2003.

And yes, it has become even more popular since.

Re:OMG enough

[Anonymous Coward]

It is called Plausible Deniability and it is as old as politics itself.

Assume either stupidity or maliciousness. It doesn't matter.

Fix the fucking software and crucify who put this in there, period.

Re:OMG enough

[Dunbal]

Maybe on the desktop it was for hobbyists but linux has been pretty solid in the server market for a number of years. It was not unheard of in 2003, and certainly still had growth potential if not the market share it has today. It's not my field of work so exact figures and citations escape me, but I'm pretty sure I'm not completely lost in thinking it a very viable target.

Re:OMG enough

[Joining Yet Again]

In 2003, there wasn't even near the IDS/IPS technology of today.

Eh, it's not changed that much. As before, it depends on admins paying at least vague attention, and things being not worth breaking in to.

Firewalls were in place, but some places still have not moved to internal segments with firewalls on the internal networks.

Unlike today, when... wait what are you even smoking?

Re:OMG enough

[Anonymous Coward]

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.

Well, that makes me more inclined to believe it was not an attempt at a backdoor. Assuming we are talking about a skilled programmer hacking, they would've made the effort to make the code compile without warnings as to ensure nobody's attention is brought to that line... All you have to do to shush the compiler is, indeed, an extra pair of parentheses. Would you have caught those be mere visual inspection?

Re:OMG enough

[Joining Yet Again]

True - that was a time of relatively strong propaganda. The decade before, it was only communists who did that. And so on.

Re: OMG enough

[Simon Brooke]

The fact that

1. This patch was sneaked into CVS bypassing the proper channels;
2. The submitter identity was (allegedly) forged;
3. The UID assignment was surrounded in parentheses to prevent a compiler warning

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:OMG enough

[F.Ultra]

Considering how b0rked this attempt was, Microsoft actually would be plausible :-). I mean is there any lint or static code analyser who wouldn't have yelled it's ass of on that line? Even GCC does it (not so sure that the version of GCC used in 2003 did this though to be honest).

Re:OMG enough

[F.Ultra]

If it had not been found by some random diff then this would most definitely been found the moment someone ran the code through lint or some other static code checker, hell even GCC would throw a warning on compile (atleast a modern version, don't know how the version from 2003 worked).

Re:OMG enough

[Anonymous Coward]

You paid by the government?

Re:OMG enough

[F.Ultra]

yeah, no one ever ran Linux on servers in 2003...

Re:OMG enough

[Dr_Barnowl]

Git is actually very hard to break like this, especially if you sign commits.

Every revision has a unique SHA-1 identifier which is an aggregate hash of the entire content of the tree, AND the commit comments, AND the preceding revision hash. Slipping something like this directly into the repository would cause a vast cascade of ID changes that many people would notice instantly. If you sign key commits and build systems that enforce the presence of those signatures, it's pretty difficult to finagle like this.

But yeah, CVS, you can probably hack on the repo with a text editor and get away with it.

Re:OMG enough

[icebike]

If it had not been found by some random diff then this would most definitely been found the moment someone ran the code through lint or some other static code checker, hell even GCC would throw a warning on compile (atleast a modern version, don't know how the version from 2003 worked).

Your assessment seems to differ with that of Simon Brooke in this same thread:
http://slashdot.org/comments.pl?sid=4319279&cid=45083911

Re:OMG enough

[TheCarp]

> It is called Plausible Deniability and it is as old as politics itself.

No there was no plausible deniability in this case. There would have been, if the author had some reason to be mucking about in those error handlers, but, for that to be the case, the author would have to be known and the change approved....

Since the change was not approved, and had no submitter attached to it, there is no entity to be accused which could then plausibly deny. Its a clear cut case of malicious action.

> Fix the fucking software and crucify who put this in there, period.

Yes, crucify Anonymous! Maybe you need to find him first?

Re:OMG enough

[Anonymous Coward]

Um... Very popular OS? in 2003?

I guess it all depends on your point-of-view. LINUX wasn't all that popular in 2003, just a hobbyist OS.... It has become more popular since.

You're off by at least a decade. Linux was a hobbyist OS in 1992 when it was at 0.98pl5, capable of running X11 and SLIP over 14.4kbaud modem. By 2003 it was running LAMP stacks all over datacenters everywhere, displacing Windows and its craptacular load of IIS, ColdFusion, and VB.NET, and per-connection licensed SQL Server.

It's never been popular as a desktop environment for the masses.

Re:OMG enough

[Anonymous Coward]

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?

Except, there's no obvious reason why you would be trying to improve the error handling of an obscure case that shouldn't happen in the wild, in a surreptitiously added update.

To put this in a car analogy, this isn't someone standing next to a car with it's alarm blaring while they fat finger their key-fob. This is someone leaning through a car's broken window while the alarm blares..

However my money would be on an independent hacker not the NSA. The NSA should have the resources to get their back-door through the approval process, and would be less likely to target the less official repository.

Re:OMG enough

[SlippyToad]

Except nobody is saying "it was the NSA".

Yes, it's almost a text-book example of a strawman argument. Someone most certainly did break into this CVS system and someone almost certainly did insert a backdoor. Not sure who it is, but of course the NSA have been pretty much admitting that they've been spying on everything we do, so it is also not really conspiratorial or hysterical to presume that they or someone like them might be pulling crap like this. However, anything unsettling that can be marked as a conspiracy immediately is, to delegitimize criticism and complaints.

Re:OMG enough

[notknown86]

"Let's just go forward with what we know"

Urgh. Frankly I prefer hypotheses and the scientific method.

Re:OMG enough

[Xtifr]

In the absence of evidence, I would be more likely to refrain from naming anybody.

Except that the NSA's hackery has been much in the news recently, so mentioning that there's no reason to suspect them in particular (which is what the article basically did) might well be worthwhile. It's basically answering a question that was sure to come up.

Re:OMG enough

[Anonymous Coward]

Thanks Virtucon, your check is on the way.

Regards,
NSA

Re:OMG enough

[F.Ultra]

Yeah I found that out some seconds ago. I did try it with GCC myself and since the uid=0 is wrapped inside their own parenthesis GCC does not throw off a warning evne on -Wextra, and a lint like cppcheck did not complain either (which pissed me off since they *should* warn about assignments in if statements if I tell it to report verbose warnings).

Re:OMG enough

[NFN_NLN]

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?

We're not "torturing" people... we're just forcefully trying to extract information from people using this new 'water-boarding' technique. No one will actually die.

Re:OMG enough

[NFN_NLN]

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.

His reasoning is right up there with, "I'm not gay, only my boyfriend is", type logic.

Re:OMG enough

[Anonymous Coward]

The code snippet changes the user id to root. No one fucks around with uid and comparisons that way. There are very, very few legitimate contexts for such a line.

I was taught to do comparisons in the opposite order of terms to avoid that very problem: "if (0 == variable)" and "if (variable == 0)" are both valid comparisons, but the typo "if (0 = variable)" throws an error while "if (variable = 0)" makes a potentially dangerous assignment. But, hey, maybe that's why I'm a classics major and not a kernel hacker.

Re: OMG enough

[wordsnyc]

Thousands of contract employees in the past few years have had access to what Snowden revealed. It is likely that all those "secrets" were old news to every major foreign intelligence service. The NSA is like a vacuum cleaner with a punctured bag: they sweep up info and then leak it like a sieve.

And if Snowden were interested in selling info, he would never have gone public.

Re:OMG enough

[girlintraining]

so far so good. but stepping back a bit. what legitimate reason would there be for wait4 to take invalid flags only if the uid is 0? this is clearly a back door.

Not to put too fine a point on this, but in Linux and Unix, uid 0 is god. There's lots of code in the kernel that says "Don't ever, under any circumstances, allow this. Unless of course God asks you to."

Re:OMG enough

[triffid_98]

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

And I for one blame the disgruntled spirit of Nikola Tesla.

Re:OMG enough

[tlhIngan]

The name attached to the log entries belonged to someone who said he didn't make the changes.

Well, it also had the fact that CVS was just a read-only clone. If you wanted to make a change, you can't submit it to CVS - you had to submit it up the change and eventually it would hit the BitKeeper repo first, then propagate to CVS.

So oddball entries like that mean it not only is a change that doesn't end up back in the BK tree (because there's no pointer back to the BK changeset), so something strange is going on.

Of course, this only affected CVS users - it would not affect BK users (as the CVS was a one-way clone of the BK tree that was autogenerated), so the change not only was only in CVS, but there is no corresponding change in the BK tree to be linked with anyone.

Re:OMG enough

[Anonymous Coward]

So unless we have full proof of who it was, their motives and a full confession, it simply didn't happen?

You are part of the problem!

Captcha: alphabet

Re:OMG enough

[Anonymous Coward]

I think what Virtucon was trying to complain about, but failed miserably in conveying, was not the claim that someone was trying to insert a backdoor into the Linux kernel, but that that someone was the NSA, as there is zero evidence to point to any suspect.

I think his post was pretty clear:

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

Re: OMG enough

[Anonymous Coward]

Yes, the cvs server was hacked, and this code added as part of that episode. Who did it and why remains an issue for idle speculation, which is what /. does best.

Re:OMG enough

[marcosdumay]

But yeah, CVS, you can probably hack on the repo with a text editor and get away with it.

I had a habit of rewritting the history of my personal CVS repositories when I used it. You can remove that "probably", you can change anything in CVS with a text editor, except for binary deltas.

Subversion is slightly better (yeah, I've edited those too). It is hard to change anything, except the commit messages (those are easy), you'll have to make calculations for setting everything up. A custom software is the best option here, but can be done.

I'm still not convinced that one can change a git or hg repository without all developers being aware of the fact. As a first guess, I'd say it requires accessing the all the development machines (a few hundred million ones in the case of Linux).

Re:OMG enough

[MickLinux]

Okay,you say should. what does the GCC source code say about that? is there an equally evil bug there, too?

And... has the other kernel source server ever been compiled off the CVS source?

Re:OMG enough

[marcosdumay]

Yes, in 2003 gcc already produced that warning. Except that there are parenthesis around the assignement (cleverly disgussed as disambiguation for the && and = operators), thus no warning is generated.

Re:OMG enough

[Kynde]

Actually, the code snippet, without context is not an obvious attempt. It is a cleverly hidden attempt that COULD be a genuine error.

Sir, you have not looked into this one bit and are spewing hot air without any substance.

The ANDed limitation of uid being root makes zero sense. Why limit root in particular?

Not to mention that __WALL already has __WCLONE flag in it, what would possibly be the point of that? Aside from the obvious assignment as comparison, which of course seemingly could be a typo, the rest of it is something no sane kernel developer would have any reason what so ever to put in there.

That is why it is a backdoor insertion without any reasonable doubt. Not because of the mere = in place of ==, which I still typo regularly after 25 years of C. Thankfully these days compiler warnings and various static analyzers catch that nonsense.

Re:OMG enough

[MickLinux]

Iirc, some have already died from waterboarding. The administration's assertion that torture is not torture is, however, a valid defense for the time being, viz., until we lose a war on our own soil.Then it becomes proof of capital crimes by the leaders of a rogue government.

Re:OMG enough

[djmurdoch]

Since the change was not approved, and had no submitter attached to it, there is no entity to be accused which could then plausibly deny. Its a clear cut case of malicious action.

It was not approved, but it did have a submitter attached to it. The name was apparently forged.

Re:OMG enough

[Anonymous Coward]

Have you stopped beating your wife?

Yep, if i remember correctly, it was right about the time you stopped screwing your sister.

Re:OMG enough

[Darinbob]

I tried to make the change first but failed. I made a bone-headed noob mistake and did "current->uid == 0".

Re:OMG enough

[Darinbob]

It's a pretty bad back door for the NSA. Too easy to find, too easy to fix, too easy to fix even without knowing you're fixing a backdoor. Linux undergoes lots of revisions and it's highly likely that the backdoor would only have made its way long term onto relatively few computers. Better would be to get a backdoor that's hard to find, and in a release that's closer to a stable release.

Sure it could have been NSA, but with my tax dollars at work I would hope they were more competent than that.

Re:OMG enough

[Anonymous Coward]

Who did this is well known in the underground, it was not the NSA. They are not omniscient, nor omnipotent. You guys sound like a bunch of hysterical girls.

Re:OMG enough

[Anonymous Coward]

Well the intelligence agencies have already proven their malice. Their own actions put them on the suspect list and they deserve it.

Re:OMG enough

[Darinbob]

Well, it's a bizarre coding error because even if corrected that entire statement is pretty messed up, Why both WALL and WCLONE for instance when WALL is enough to cover WCLONE case, why have that check only for root, etc. It clearly looks like it was designed to slip past someone casually looking at the code although an expert at the code might get suspicious.

The diff however was not random. It was done as the standard procedure when synchronizing the code between BitKeeper and CVS.

Re:OMG enough

[jcochran]

Obviously you're unaware of how GCC works. Yes, it would have issued a warning message if the line was:
wait4: if ((options == (__WCLONE|__WALL)) && current->uid = 0) ...

But the author of that little backdoor attempt added the extra 'superfluous' parenthesis around the assignment. Like this:
wait4: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...

And GCC uses those extra parenthesis as an indication that 'The assignment is deliberate and desired. Don't warn me about it. I know what I'm doing'
In fact, GCC still uses those extra parenthesis as an indication that the warning message should be suppressed.

Re:OMG enough

[sjames]

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

So that would be 'someone' inserting a backdoor into the kernel then? Isn't that what TFS and TFA said?

There really is no other reason to put that code in, or even that code with the current->uid== 0. It only makes sense as a backdoor.

As for mentioning the NSA by name, lat's say you live in a town and someone stole all the apples, There's the mayor, the police chief, the minister, and light-fingers Louis, convicted 3 times for stealing apples. I WONDER who I should investigate first.

Re:OMG enough

[LanceUppercut]

That is actually misguided reasoning. If you remove this parenthesis and write it like that
if ((options == (__WCLONE|__WALL)) && current->uid = 0)
the code will fail to compile for a completely different reason. In C (as well as in C++) the assignment operator has very low priority, lower than `&&` operator. That means that the above code would be interpreted as
if (((options == (__WCLONE|__WALL)) && current->uid) = 0)
A code like that would not compile at all, since it attempts to assign 0 to something that is not lvalue. For this reason (and not some "warning"), you actually absolutely need that extra parenthesis.
Also, note that the first condition is also wrapped in parenthesis, which is formally excessive ('==' has higher priority than `&&`, but some users prefer to add that extra parenthesis since they believe it improves readability). For this reason, it is fairly safe to conclude that both parentheses where there from the very beginning. They were not added by that malicious coder.

Re:OMG enough

[Raenex]

"We've traced the call... it's coming from inside the house."

Re:OMG enough

[sjames]

Except that to get those lines of code there, someone had to hack the read-only CVS repo first. Any legitimate contributor would have submitted the patch properly and have it go through the review process. Then if it slipped throyugh with that error, it would have been checked in to the BitKeeper repo and finally copied to the CVS with a log entry.

As for the NSA, it is one possibility. Like many government operations it has a number of highly skilled people in the rank and file and a management that couldn't find their own ass with both hands and a map.

Re:OMG enough

[LanceUppercut]

Er... You do realize now that there has never been any "hackers", do you? The whole concept of "hackers" was nothing more than a smoke screen invented by NSA for the sole purpose of creating FUD in situations like this one. Hollywood picked it up and ran with it (maybe on their own accord, or maybe after receiving a few of offers they could not refuse), so the idea of a "hacker" eventually became a part of pop-culture. But it no "hackers" ever actually existed in real life. It is time to wake up, it is 2013 already.

Re:OMG enough

[hairyfeet]

Not to mention have you SEEN the winners of the obfuscated C contest? the kind of guys that get jobs with the NSA frankly aren't THAT damned sloppy!

At the end of the day it really doesn't matter though, as we have seen with the Tor nodes being run by the NSA there is more than one way to skin the cat and anybody can write a Linux virus in 5 easy steps by simply targeting the same weak link as on Windows and OSX...the user. BTW anybody that doesn't think it would work should look up the "KDE Look Bug" that worked by using the classic trojan move of bundling malware with something the user wants, in that case a theme and screensaver for KDE.

So the moral of the story is there really is no need for the big bad to manage to hack the Linux kernel, or the Windows or OSX kernels, there are a million other ways to gain control of the system. Quick, show of hands, how many here have done a code audit on Libre Office? Firefox? What about all those little programs that end up in every distro, from the stylish digital clocks to the little googly eyes app? How many have done a serious security minded code audit on those? Just remember because something COULD have been done does NOT mean it HAS been done, after all someone could become a zombie but I really don't think I need to worry about the undead eating my brains, do you?

This is just a wake up call that NO OS is immune, no OS is magically free from zero days or attacks, that is magical thinking and ask all those OSX guys that got MacDefender and macGuardian bugs where magical thinking gets you.

Re:OMG enough

[Anonymous Coward]

But it's hardly a wacky assertion that it could have been the NSA.

In the absence of evidence, I would be more likely to refrain from naming anybody.

Except nobody is saying "it was the NSA".

Are you bipolar?

Re:OMG enough

[Anonymous Coward]

Actually the parentheses are required, since && has higher precedence than =.

if ((options == (__WCLONE|__WALL)) && current->uid = 0)
doesn't compile since the expression "(options == (__WCLONE|__WALL)) && current->uid " isn't an lvalue.

GCC does suppress the warning in expressions like if ((x = 0)). So I'd almost say that it's a bug in GCC that it doesn't warn here—I think it should only suppress the warning if there are more parentheses than necessary, so that one would have to write

if ((options == (__WCLONE|__WALL)) && ((current->uid = 0)))

to suppress the warning, and that would raise a few more red flags in anyone reading the code.

Re: OMG enough

[dbIII]

From what he's revealed so far about how shambolic the outsourced bits of the NSA are and the limited interest of the Russians in him it's probably a fairly safe bet that he has nothing to sell to the Russians that they don't already have. The Chinese were not interested in him either.

Re:OMG enough

[dbIII]

It apparently regularly shorts out in spectacular fashion shooting bolts of lightning between racks of equipment

What fun, playing with DC powered racks and enormous copper busbars without a clue I presume. Do you have a link to anything about it?

"Never attribute to malice that which can be explained by stupidity."

Except in this case it can't be explained by stupidity because something that is supposed to be a read only copy is not the same as the original. Whether the NSA is involved or not can be nothing but wild conjecture but it's very clear that somebody was up to no good.

Re:OMG enough

[dbIII]

I had a production cluster, an R&D cluster, file servers, a mail/web server and about 20 desktops in this place running linux in 2003.

Re:OMG enough

[Anonymous Coward]

That's not right.

Whoever added this added the parenthesis around (options == ...) *in order* to make it natural to have parenthesis around current->uid = 0.

If you have parenthesis around one, but not the other, then you easily spot the awkward expression and see what is wrong.

        if ((options == (__WCLONE|__WALL) && (current->uid = 0))

*absolutely* sticks out as dubious, but by adding the extra parenthesis arond the first expresion it does not.

Thus I side with the grand-parent poster.

Re:OMG enough

[akita]

undoing wrong mod, sorry :)

Re:OMG enough

[mSparks43]

Is it just me, or does having a uid == 0 == Root, seam really f'ing stupid, bad code design?
Why is it this way? surely it would be better to use some run-time generated uuid only accessable to a Root account?
Then a quick code search can keep track of everything getting this uuid.

Just seams bad to me that getting root access should be as simple as setting user id to zero.

Re:OMG enough

[TranquilVoid]

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.

Something that makes it slightly less likely to be a genuine coding error is the presence of parentheses around the erroneous clause. The difference in precedence makes them unnecesary for == and necessary for =. Of course the prior == clause has them too and some programmers follow the 'remove all ambiguity and always use them' rule.

Re: OMG enough

[F.Ultra]

Yeah sorry about that. Have seen GCC throw warnings on the few ocassions where I did similar things in error so I was temporarely unaware of the paranthesis supressing the warning. Something that I *should* know since I use it myself on several occasions (with fread and so on). However a lint type of code analyzer should imho have a flag to enable warnings in these circumstanses.

Re:OMG enough

[Ash Vince]

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

Did you bother reading the full article? If you did you might have picked up on what made them think it was a backdoor attempt:

"Further investigation determined that someone had apparently broken in (electronically) to the CVS server and inserted this change."

That is not the normal behaviour of developer submitting a patch to the linux kernel. It is also not normal for the developer who has his name next to the patch in the CVS log to deny categorically ever committing the patch.

In this case it seems weird as well because Linus did not use CVS at all since he used BitKeeper so the only way this change would find its way into the kernel was if a trusted developer pulled the code from CVS, did a chunk of development work then submitted a patch to Linus which he approved containing this bug. There are a million reasons why this was probably never going to happen though, starting with that fact that the developer would have to be editing this same line for the patch to contain it.

You're right though in that if this was a patch that went into BitKeeper trunk or whatever (hey guess what, I know nothing about bitkeeper) via the normal process this would be more clearly down to a developer screwing up but the weird nature of this going straight to CVS rather than than via BitKeeper is what makes it look suspicious.

Re: OMG enough

[Anonymous Coward]

PC-lint would have caught that even with the parentheses, though.

Re:OMG enough

[david_thornley]

Having been a CVS admin, over ten years ago....

CVS was originally a set of scripts over the ancient RCS, and (at least when I ran it) used the RCS file format. This is, essentially, the current text of the file followed by change records in reverse order for the trunk and increasing order for branches (and when there were a lot of revisions on both trunk and branch after the branching point, things got slow). There were no checksums, so files could get corrupted, likely losing history. Each file had its own ,v RCS file in the repository. You could build a repository by creating the framework and moving in ,v files.

This means that, to alter foo.c without a commit, one would have to get write access to foo.c,v in the repository, and simply make the change. To keep the repository consistent, the change couldn't change the number of lines, as the change records depended on line numbers.

All other modern or semi-modern VCSs that I know of have their own file format, and require some more sophistication than a permissions hack (assuming permissions were properly set in the first place) and using vi on the obvious file.

Re:OMG enough

[Peaceful_Patriot]

Paranoia or not, the NSA or its precursors have been aggresively working for years to get access to your data and break or bypass encryption. Sure, it could have been a hacker or bored student, but its just silly to think Linux users are immune to the attention of government prying eyes.

Re:OMG enough

[LanceUppercut]

Firstly, you are still missing the main point. The "grandparent poster" is factually incorrect in his/her assertion that parenthesis is optional and was added just to camouflage the modification. You simply don't get to side with that poster, regardless of whether you want it or not. The option is simply not on the table, period. The parenthesis is not optional in this case, so the matter of whether the malicious coder was thinking about using it to better hide the change is completely moot. Whatever they were thinking does not matter, since the compiler would force them to add the parenthesis anyway.

Secondly, I suggest you look through a few Linux source code files and observe the styling conventions they use here. You will find massive amount of formally superfluous parenthesis usage in expressions like (a == b) && (c < d). Do you really suggest that this was done by hordes of malicious coders trying to hide something?

Re:OMG enough

[kermidge]

Nope, came from some careless reporters working a story on the "411" phone phreakers in Milwaukee circa the Seventies. I had a link to the wire service stuff and the back story, which I can't now find - I hope it's still somewhere on an old drive. Still, one ought to be able to dig up the correct references and all.

And "hack" itself comes from WWII and the services (there may be earlier references; I can't recall.) If one could bear up under a load or circumstance, they could "hack it." Extended to "Can you manage this shit?" "Yeah, I can hack it." and went on to "Can you fix this goddam radio?" "Yeah, I can hack it." I've read enough examples from that time, if memory serves. Again, references ought to be findable. The Brits (with some bleed into Allied usage) had the "time hack" (and yes, they actually said "hack") when synchronizing timepieces; the U.S. often used "mark" for the same use, as they also did for denoting a time or position for one to make note of NOW, as when taking a bearing or azimuth.

Re:OMG enough

[Anonymous Coward]

The TFS author was very clever. He/she tosses in the NSA's name, and then quickly backtracks to make sure they can later claim that they never accused the NSA of anything. That way, they toss in some tinfoil hat wearer fodder, but retain deniability. So later on, we have the following scenario:

CONSPIRACY THEORIST # 1: "Look, it was the NSA!"
CONSPIRACY THEORIST # 2: "But the article doesn't say it was the NSA! It coulda been the Chinese!"
C.T. # 1: "But the Chinese aren't mentioned in TFS!"
C.T. # 2: "So what? TFS never claimed it was the NSA!"

Sheeple opinion management (i.e. subtle brainwashing) at its best!

Re:OMG enough

[Anonymous Coward]

Most cracking these days, is done by government. Out of those, I'm sure the US is one of the more active governments in this area. Thus, calling it some random hack with no government involvement is a more speculative statement.

Phew!

[cyberpocalypse]

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

Re:Phew!

[Anonymous Coward]

You're not a programmer, are you?

Felten

[Anonymous Coward]

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

Repost

[Anonymous Coward]

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

[jones_supa]

Agree. Everyone knows this already.

Re:Repost

[squiggleslash]

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

[Sarten-X]

I can see why the original submission was edited.

No mention of a Raspberry Pi.

Re:Repost

[i kan reed]

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.

Re:Repost

[Anonymous Coward]

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

Re:Repost

[neo-mkrey]

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

Re:Repost

[VortexCortex]

BINGO!

Thank you!

I just won another round of conspiracy theory bingo. It's like the regular bingo that grandma likes, with a lot more "Ha! I knew it!"s just for grandpa.

Re:Repost

[oodaloop]

Or 3D printers.

Re:Repost

[Anonymous Coward]

Snowden gave the evidence to Assaunge so it must be true.

Re:Repost

[Anonymous Coward]

Be careful, Linus Torvalds has specifically repudiated that he was approached, he clarified that he was joking.

However, as far as I'm concerned Linus is an idiot for 'joking' about that in the first place.

Fanboys blaming everybody but Linus instead in 10...9...8...

Re:Repost

[dohzer]

Yeah, but that was before all this NSA shit. Times have changed!

Type safety

[TechyImmigrant]

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

[piripiri]

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

Re:Type safety

[ggraham412]

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

[fisted]

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

[Kaenneth]

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

[Anonymous Coward]

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

Re:Type safety

[lesincompetent]

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

[ninlilizi]

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

[Kaenneth]

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

[mrchaotica]

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

[Anonymous Coward]

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

[TechyImmigrant]

That would be a neat attack vector.

user = 'low_priority_user'

Parsed as root, reads like not root.

Re:Type safety

[TechyImmigrant]

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

Re:Type safety

[lesincompetent]

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

Re:Type safety

[TechyImmigrant]

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

Re:Type safety

[lgw]

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.

Good thing C doesn't have Booleans, then.

It helps to remember that C was intended as a fairly thin layer over assembly. In assembly you can set one register to the value of another, then branch-if-not 0, Two instructions on most platforms. Why should that be an error? Of course, one hopes than on most modern compilers it's a warning.

Re:Type safety

[jandrese]

666 is a pretty evil permission actually. Making a file world writable is just asking for trouble. I'm also shocked at the prospect that a Jack Chick type pamphleteer would understand Unix permissions. Those people are usually quite technologically challenged.

Re:Type safety

[TangoMargarine]

Versus using a language that's less than 4 years old...what could possibly go wrong?

Re:Type safety

[Anonymous Coward]

16 bits UNSIGNED but 65535 is not usable (== -1) a long time ago. This condition can still rear its ugly head under degenerate conditions so root still has to comply.

Re:Type safety

[ultrasawblade]

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.

Re:Type safety

[ais523]

I like this trick, and am glad that you're publicising it. It was a pretty clever addition to many compilers; the compilers that don't understand it won't reject the code, the compilers that do will know it's intentional. And maintenance programmers reading the code will know it's intentional, too.

Re:Type safety

[FunkyELF]

no need to publicize it... just compile all your code with -Wall -Werror

Re:Type safety

[lgw]

Ooo, a cyber-stalker! Neat, I always wanted one of those.

Re:Type safety

[Anonymous Coward]

unless you come up with more details, i'm calling bullshit.
what "launcher" were you using? what distribution. i've
never seen anything in the last 20 years make that error.

Re:Type safety

[Hognoxious]

For some reason, I'm thinking of lightsabers.

And it's not something I do every parsec.

Re:Type safety

[Anonymous Coward]

Pascal had it right with := being the assignment operator.

Pascal of course (well, N. Wirth) borrowed it from the Algol series of languages.

The reason C didn't use it was because Kernighan et al were lazy typists and because even disk memory was not cheap in those days. Same reason for replacing Algol/Pascal's BEGIN...END with {...} and dropping THEN.

Re:Type safety

[F.Ultra]

I thought so too, but apparently by wrapping the statement in parenthesis "(uid=0)" the compiler warning goes away, not even -Wall -Wextra shows a warning then.

Re:Type safety

[disposable60]

Assuming your timing control is good. Metastable latches make your bool a p() function.

Re:Type safety

[TechyImmigrant]

Which is handy for building a random number generator.

Re:Type safety

[marcosdumay]

The problem is not even the name of the "=" and "==" operators. The real problem is that C supports statements like a = b = c = 0, and for that requires that "=" return a value.

Re:Type safety

[organgtool]

So if the superuser is not zero, there will be a performance penalty.

That's why I run all my tasks as root!

Re:Type safety

[Kaenneth]

It was a ReplayTV DVR emulator back around 2005. I reported the issue, and it got fixed in the next release.

Re:Type safety

[fisted]

I thought so too, but apparently by wrapping the statement in parenthesis "(uid=0)" the compiler warning goes away, not even -Wall -Wextra shows a warning then.

First of all, uid=0 isn't a statement (uid=0; would be), but an assignment, and hence an expression.
gcc /does/ warn, if the result of such an assignment (i.e. the value the expression evaluated to) is used as a truth value (i.e. in a logical context).
This means, that

if (uid = 0) {}

will generate a warning, as intended. (Note that the assignment is still /not/ considered inside parenthesis, as the outermost parens are part of the ``if''
To silence the warning, you'd surround the assignment in parens:

if ((uid = 0)) {}

will /not/ generate a warning.

Re:Type safety

[Anonymous Coward]

Actually that's why Windows ran everything as root prior to UAC... for performance reasons, yea that must be it..

Re:Type safety

[Anonymous Coward]

I agree that you are insightful about = vs == (or more directly, that assignments within expressions was a text-savings technique from the days when memory was limited and as such does not have obvious justification in todays world) but there is no real reason for a high privilege UID's value to be chosen based on vague efficiency gains so in that regard I do not think that you are insightful but instead just shallowly informative.

If there are frequent tests (millions of times per second) of the UID for high level privileges then the problem isnt the efficiency of the test, while if the tests are infrequent then it doesn't matter how efficient the tests actually are as long as they arent absurdly inefficient.

Here we are talking about maybe 3 cycles of extra latency at most for a comparison instruction, but more likely it will average way below 3 cycles on modern pipelined processors. 3 cycles of extra latency might matter in an inner loop of some kind, but such tests shouldn't ever be inside any inner loop where efficiency matters.

Re:Type safety

[david_thornley]

No, I'm going to say that the base problem is C's lack of a boolean type. Because of that, C takes anything that could reasonably be said to be equal to zero as false, and everything else as true. Given an actual boolean type, a conditional statement could require a boolean expression and flag anything else as an error. The ability to use the value of an assignment statement is occasionally convenient, but the ability to use it as a condition is a serious problem.

C's use of = and == as operators is a bit problematic, but Pascal's := is a pain. On every single computer or terminal keyboard I've used in the past forty years, either the : is shifted xor the = is shifted, which means that I have to change the shift key in the middle of an operator. It's not as annoying as some of the other things with Pascal, but it's a bit of a pain.

Re:Type safety

[marcosdumay]

Given an actual boolean type, a conditional statement could require a boolean expression and flag anything else as an error.

if ((error == ERRCODE_1 | ERRCODE_2) && (isRoot = true))

Now, what did you gain?

For the one you catch, how many do you overlook?

[Anonymous Coward]

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

[oo_00]

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

C/C++ operator =

[Jamu]

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 =

[tuffy]

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 =

[Anonymous Coward]

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 =

[Anonymous Coward]

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 =

[TheCarp]

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 =

[Anonymous Coward]

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

Re:C/C++ operator =

[Anonymous Coward]

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 =

[Anonymous Coward]

Oh yeah? We'll C also broke centuries of tradition of doing all your math by hand. Live with the progress, live with the syntax.

Re:C/C++ operator =

[dfghjk]

"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:C/C++ operator =

[camperdave]

I recall reading about a compiler or interpreter somewhere along the line which actually would redefine the value of the "constant" 0. So although it will catch errors, it may not always catch them.

Re:C/C++ operator =

[Anonymous Coward]

Shh... Best to let the fool bask in his momentary revelation.

It's sad really. For all our virtual get togethers, there's a lot of knowledge that just doesn't get shared between basement nerds. Someday... someday...

For now, we must await the Singularity. The great uniting of minds. Only then shall we emerge victorious from our subterranean shelters, united as one: The Ultra Uber Geek -- A digital manifestation of all the best practices for leveraging the ultimate in human cognitive power: Snide remarks so contemptuous they rip pride from marrow.

Re:C/C++ operator =

[swillden]

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.

No, assigning to a non-lvalue (where lvalue is defined, essentially, as "something that can be assigned to") has never been legal C or C++.

What would it even mean?

Re:C/C++ operator =

[phantomfive]

Unfortunately there's a lot of old code that doesn't do this

I still write new code that doesn't do this. I think about people like you every time I do it though, so at least I'm thinking of you. That's something.

Re:C/C++ operator =

[Anonymous Coward]

> 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.
Sorry, but no. That's what you get when you have moronic rules like "a no-tolerance policy for warnings". No tolerance = no intelligence. The thing that is screwed up is your process, not compilers issuing warnings.

Re:C/C++ operator =

[Kjella]

Personally if I was designing a language I'd ban the single = operator and use := for plain assignment and == for comparison. Compound assignment like += could remain the way they are. Is it extremely unnatural and annoying to write stuff like if (3 == foo ), I'd be a lot more obvious and a lot less likely to be a typo if it had to say if( foo := 3 ) to do something bad. Of course it could still be a brain fart, but a pretty bad one at that.

Re:C/C++ operator =

[TheCarp]

I think I read the same thing, or something about the same issue. I always remember seeing some examples of this and the odd and what it would lead to. For some reason, I remember C being the language in question, but maybe not.

Re:C/C++ operator =

[Anonymous Coward]

the pedantic answer is that NULL is not always 0, but expression NULL == guarantees a) that whatever is being evaluated is checked for NULL b) it cannot be assigned to and would throw an error.

I think explanation this was buried in the C/C++ lang FAQ when newsreaders were the rage....

Re:C/C++ operator =

[tuffy]

The simpler approach is simply to make variable assignment a statement rather than an expression, so if (a = 1) ... is no longer syntactically valid. It enforces more language verbosity while eliminating a class of potential bugs.

Re:C/C++ operator =

[Anonymous Coward]

The language is FORTRAN and they fixed it before FORTRAN 77.

Re:C/C++ operator =

[Anonymous Coward]

You don't write real C code, do you?

Re:C/C++ operator =

[Anonymous Coward]

What's this "It is C which..." crap? Yes, C breaks a convention, but we're talking about another convention: Lagrange and others wrote "if n is equal to 0" not "if 0 is equal to n". Jamu is breaking that one. Pointing out someone else's crime doesn't excuse his wrongdoing.

Re:C/C++ operator =

[Anonymous Coward]

Yeah, why not punish everyone and impact readability across the industry for little errors like this. Errors which, other readers have pointed out, are already flagged by GCC (and other) compilers as warnings.

That kind of code just doesn't read well. Sorry but it has no place in my programs.

Re:C/C++ operator =

[Anonymous Coward]

I wish more people would do this since it is purely a good idea. The arguments against are VERY sketchy ("but I would rather think it is pretty than correct") and most people I know who have used this pattern eventually started to find it visually very helpful (since it makes it easier to distinguish between arithmetic comparisons and logical comparisons and also to identity sentinel values).

The number of languages where this pattern is useful is staggering and goes far beyond C-lineage languages but those are the most obvious places.

It is also a good idea that new language designers make assignment not return anything, meaning it would be incorrect to put an assignment in that context, no matter how it is expressed.

Re:C/C++ operator =

[Admiral_Bob2000]

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:C/C++ operator =

[ais523]

It's best known for working in some old, buggy FORTRAN situations. Nowadays, it's legal INTERCAL too, albeit mostly to be perverse (and in some compilers, you may have to alias the constant to a variable to be able to assign to it without the compiler complaining).

Re:C/C++ operator =

[Squidlips]

But then you would be flooded with warning messages for some legacy system. Some would be bugs, some exploits and most would be deliberate attempts by programmers showing how clever they are.

Re:C/C++ operator =

[Anonymous Coward]

Writing expressions backwards hampers the readability of code and only theoretically catches problems.

I happen to agree with you about hampering readability. However, you're off the deep end on "only theoretically catches problems." Dude, writing it backwards *results in a compile error*. That's waaaaay better than "only theoretically."

Or are you one of those developers who deems all security exploits unpossible, because "nobody would do that anyhow"?

Re:C/C++ operator =

[Dogtanian]

Yeah, I'd often thought that the := operator should have been used instead of = (possibly leaving == as the equality operator and having a single = give a compiler error).

The only problem is that := *might* look quite similar to != (i.e. doesn't equal). If we were starting again from scratch, of course, we could choose BASIC's <> instead to avoid that problem, but whether it would be a good idea now, I don't know.

Re:C/C++ operator =

[Anonymous Coward]

and only theoretically catches problems

Readability is just about habit. I have caught 2-3 bugs with people not doing this in code reviews. Hell they even checked it in with a warning from the compiler. If they had flipped it around they wouldnt have checked it in at all as it wouldnt compile, wasting my time.

It is a good practice. Until you run into someone like you. Then they bitch about how they feel it doesnt look right. Using implied bits out of a language because you know it works is even worse. I work with people who have been doing it just as long as your '20 year vets'. What is they bitch about? The style. I found the easy way is to get a manager to say 'this is the style shut up about it and get back to work'. The style guide then has lists of explanations why the style is what it is.

Sometimes the answer is be better at what you do
That works for *you*. What about the next poor guy put onto your team? Is he up to the task? He just got out of college and does not have 10 years exp in finding stupid bugs. Are your teammates up to the task? It is not a crutch. It is a way to make bugs easy to find. If you want hard to find bugs those are in good supply in many projects why make more? Code is not always about you.

At my new job there are debates on what compiler warming levels to adopt
Max. Dont fart around with it. They are warnings for a reason. Dig into a few of them and you will find a few 'how does this work' bugs, and a few 'shut up compiler I know what I am doing' bugs. If you are not going to fix them then that is a different issue. Take something as simple as a downcast/sign warning. That can be used to create buffer overflows/underflows. You can then ask are you using too much memory space? Perhaps the inputs are too big and the dest is too small? Leaving warnings behind is just sloppy. I will even say your own words back at you 'Sometimes the answer is be better at what you do'. Warnings are clear sign of someone not thinking or poor design, or a mistake/bug.

there's a large code base that will never be warning-free
Then your management needs to decide if it is worth the time to fix. If not then turn it off. If so suck it up and fix it. Its probably 1-2 weeks of work. I have never had one so bad it took 10 programmers 3 months of work. Many times I can assign a junior/senior programmer pair to clean it up within a few days.

My first task with many code bases that are having 'issues' is to turn the warning level up. It finds the 'easy' crap. My next step is valgrind and boundschecker like tools, then lint set pretty aggressive. Use your tools. The easiest tool you have is the editor itself.

pollute your code with compiler-pacifying turds
Then your code reviews are failing to do their job and you are making the problem even worse by hiding it.

Yes it is suck work, not all programming is cool. But the mess does not just go away if you hide it.

Now after basically yelling at you I will tell you why, 0 warnings is good to achieve. If something suddenly gets checked in with a few issues you can catch it quick instead of 3 months from now at 3am and your tired. Instead of 1323 warnings and now there are 1328 warnings. Would you catch that 5 new possible issues have been added? Even first thing 8am morning and you just came off a 2am call? However if it went from 0 to 5 that would wake you up a bit.

Re:C/C++ operator =

[Anonymous Coward]

You've never used any language outside the C family, have you?

Re:C/C++ operator =

[Anonymous Coward]

This is what you get when you create compiler-enforced "rules"

Yoda conditions are a workaround for not using tools, a compiler with warnings enabled will tell you when you are wrong, even a beginner does not have to sound like a green gnome if he uses the tools he has right.

The reason is the release process enforces a no-tolerance policy for warnings

Zero tolerance policies tend to be rooted in either a) I have no idea what I am doing and dont want to be responsible or b) thinking is hard, lets go by the book. That said if you enforce no-tolerance for warnings on release, just use a stricter level while developing - It will be better than just ignoring the warnings completely.

Re:C/C++ operator =

[Anonymous Coward]

What would it even mean?

"Double-rainbow, oh-my-god."

Duh.

Re:C/C++ operator =

[Error27]

I actually fixed one of these bugs in the kernel last month.

But you are right that these are very rare. I have did a git search of patches which only add a single '=' character and there are normally two kernel bugs like this per year. In other words, we have 50,000 patches per year and only 2 patches have this sort of bug.

I have spent quite a few days auditing for these bugs in the kernel. They were rare the first time I audited in 2002 but these days we have several ways to make them even more rare.

Imagine you have "if (x = foo) {":
1) GCC suggests using extra parenthesis around the assignment like "if ((x = foo)) {"
2) Checkpatch.pl suggests breaking it up into two statements. "x == foo; if (x) {".
3) Static checkers complain about it if foo is a constant, or if the checker is in verbose mode, then it complains if foo is not a function call. (A lot of static checkers complain. It's a favorite thing to look for).

One thing that I have just thought of is that we should have a warning where checkpatch.pl complains if people do: "if ((x == foo) || (x == bar)) {". Sometimes it's hard to know where to add parenthesis for readability, but for comparison operations the parenthesis are obviously bad style.

Re:C/C++ operator =

[Anonymous Coward]

Depends what you mean by "fixed". It's not legal code in standard Fortran, but it's possible to do it in ways that aren't caught at compile-time. If the compiler isn't careful with how it manages constants, then hilarity can ensue. I accidentally redefined 0 in a Fortran 9x application compiled with Visual Fortran (I think the last version branded as Digital, which would have issued in the late '90's). I wound up having to do assembly-level debugging to figure out why I was getting bad answers.

Re:C/C++ operator =

[Anonymous Coward]

Then you could get all messed up with those single line operators like: if (A B) : A := B ? A := C;

Re:C/C++ operator =

[mirix]

Obviously it should define '0' as a variable, and then set its value to that of uid...! :p

Re:C/C++ operator =

[Anonymous Coward]

i'd rather abdicate to a software tool than an arrogant tool

Re:C/C++ operator =

[Anonymous Coward]

I take it you will never be a Haskell programmer.

Re:C/C++ operator =

[Anonymous Coward]

Actually there is a tooling support for this as well. If your editor would use different colors or some other indication to enhance the difference, this problem is also eliminated.

Re:C/C++ operator =

[Dogtanian]

What are you trying to do there? If you're talking about the ternary operator " .. ? .. : .." then I don't see how that's a problem as syntactically a "=" symbol can't follow the colon (either by existing or changed rules), so it could only be parsed as a single ":=" operator. Not ambiguous AFAICT.

Re:C/C++ operator =

[Anonymous Coward]

1) It's a true sense of security: You can't assign to constants.
2) There are such things as C/C++.

Re:C/C++ operator =

[Anonymous Coward]

The equality operator is commutative. If it reads differently, then you're reading it wrong.

Re:C/C++ operator =

[Anonymous Coward]

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.

Yeah you can't treat the terms in an equality operator equally. Equality operators that treat both orders the same are for weaklings. I also insist on one particular order, not as a crutch, because I'm a strong programmer. It's the other programmers using any order - including the one with less bugs - that are the weaklings using a crutch. I'm stronger that that! I like equality operators that depend on the order of their terms.

I love using unscoped local variables in switch statements. That's never a problem in my code. Unscoped local variable are a crutch for the weak! People testing my code all seem to have the same attitude you mention. I hate them.

I don't abdicate to tools I don't control of even understand! Hell no! That's why I also turn off compiler warnings and/or litter my code with turds.

Re:C/C++ operator =

[Anonymous Coward]

How about no. I would rather program in normal math than in some cryptic nerd dialect.

Re:C/C++ operator =

[Anonymous Coward]

C and C++ have a large intersection but they are different languages.

Writing C/C++ only highlights what a clueless dumb-fuck you are.

Re:C/C++ operator =

[columbus]

I was going to mention this one, but you beat me to it. Someone mod parent up please.

#1 on this list of new programming jargon
http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html

Some of my other favorites in there: the Common Law Feature & Hooker Code.

NSA (Probably) installed one Anyway

[ObsessiveMathsFreak]

Article overlooks the other big backdoor which was installed in 2003: SELinux.

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:NSA (Probably) installed one Anyway

[Anonymous Coward]

>I still have no idea why my kernel would need an internal firewall
That's because you're retarded.
>Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides the mechanism for supporting access control security policies, including United States Department of Defense-style mandatory access controls (MAC)
If you don't like it, don't compile it into your kernels. Many people who deal with mutliuser systems require ACLs and MACs.

Re:NSA (Probably) installed one Anyway

[jandrese]

I thought SELinux was a clever plan to make security so obnoxious that everybody turns it off and leaves their machines vulnerable to attack.

Re:NSA (Probably) installed one Anyway

[bill_mcgonigle]

Many people who deal with mutliuser systems require ACLs and MACs.

Yes, but the remaining question is "why does Snowden have a slide deck on SELinux?".

Perhaps it's the *only* example he could find of NSA doing good work that did not subvert Americans' security so he took it along to demonstrate fairness.

Or perhaps not. For now I'm using selinux=0 on the kernel command line and separating concerns with virtual machines.

Re:NSA (Probably) installed one Anyway

[myowntrueself]

Many people who deal with mutliuser systems require ACLs and MACs.

Yes, but the remaining question is "why does Snowden have a slide deck on SELinux?".

Perhaps it's the *only* example he could find of NSA doing good work that did not subvert Americans' security so he took it along to demonstrate fairness.

Or perhaps not. For now I'm using selinux=0 on the kernel command line and separating concerns with virtual machines.

Does having selinux=0 on the commandline mean that all selinux patches in the kernel do nothing whatsoever? Wouldn't it be better to, somehow, get a kernel with absolutely no selinux code?

Re:NSA (Probably) installed one Anyway

[bill_mcgonigle]

Does having selinux=0 on the commandline mean that all selinux patches in the kernel do nothing whatsoever? Wouldn't it be better to, somehow, get a kernel with absolutely no selinux code?

Probably, but make sure whoever is providing that kernel for you is also providing you with security updates so you're not jumping out of the proverbial pan.

Re:NSA (Probably) installed one Anyway

[david_thornley]

Your kernel may not need an internal firewall. Mine certainly doesn't.

However, on a system with numerous users and various data files that only some people should have access to, it can be vital to have a reliable mechanism to run programs and handle users with minimum privileges and access. It can reduce various attack surfaces. It's fundamentally a security feature for people who need strong internal security, or who just want confidential files on a system not-entirely-trusted users are allowed onto.

Re:NSA (Probably) installed one Anyway

[kermidge]

Bill, Tonika looks interesting; not that I've looked all that much, but hadn't heard of it, so thanks for the link.

This is the reality, no need for tinfoil hats

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Manfre]

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.

Wow

[ggraham412]

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

I did it.

[cellocgw]

Signed,
Spartacus

Re:I did it.

[Anonymous Coward]

No, I broke the dam.

Re:I did it.

[houghi]

I was Anonymous before it was cool.

Signed,
Spartacus

Re:I did it.

[Anonymous Coward]

Wait....I'm Spartacus.

Re:I did it.

[Anonymous Coward]

So you were Anonymous when it was lame. Gotcha.

How did this happen?

[slashmydots]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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

Re:How did this happen?

[gstoddart]

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.

Re:How did this happen?

[Anonymous Coward]

____

Give me an R!

__R_

Give me a T!

__RT

Give me an F!

F_RT

Give me an A!

FART

And here comes a nice long line to please the Slashdot filter. Haprolike redreta foo barta grop relitan se semus alter.

Re:How did this happen?

[Anonymous Coward]

It is very possible to change code within CVS without a checkin/log/record if you have access to the back end repository. I've done it myself... not that it's something I encourage, but I have done it.

Eleven years

[Anonymous Coward]

Slashdot has sucked for ELEVEN YEARS.

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

a lot of hot air, slashdot fodder and a troll

Re:Eleven years

[Anonymous Coward]

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

[Anonymous Coward]

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

[jones_supa]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Too easy to shoot yourself on the foot

[mjr167]

Kids using eclipse who don't test their code do it that way. Those of us who like to be able to read our code do it the readable way.

Telling everyone to put the constant on the left is like telling everyone "don't use pointers and you won't have memory problems". The real solution is to not write bad code.

The other tipoff

[Anonymous Coward]

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

Do not attribute to malice...

[Anonymous Coward]

...what can be adequately explained by stupidity.

Re:Do not attribute to malice...

[mrchaotica]

That doesn't apply when you already know they're out to get you.

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

[Anonymous Coward]

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

[AuMatar]

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.

I hope they monitor integrity more carefully

[guanxi]

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.

Re:I hope they monitor integrity more carefully

[Todd Knarr]

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:I hope they monitor integrity more carefully

[guanxi]

Thanks for the explanation. One point I don't quite agree on:

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.

I think you are underestimating the value to attackers of compromising Linux, and therefore everything that runs on Linux. Paying someone over several years to build a reputation in a community is nothing for a state intelligence budget or even unusual activity (based on my very limited knowledge).

Also, in IT security, insiders are often considered the greatest security threat. Established community members can be compromised; maybe they need money; maybe they believe the national security argument ('this will stop nuclear proliferation'), or they did something embarrassing, or they want to feel important, or they are angry at Linus or the community ...

Re:I hope they monitor integrity more carefully

[Anonymous Coward]

Or it could have been a man-in-the-middle attack between one of the submitters and the server. That reduces the odds down to someone with network access to the computer systems of either parties or the network itself.

Re:I hope they monitor integrity more carefully

[Anonymous Coward]

how about finding someone with reputation...plant a dead hooker in a kernel summit hotel room....send al pacino....profit.

Re:I hope they monitor integrity more carefully

[Ash Vince]

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.

Exactly.

I remember the Con Kolivas strop a few years ago and thought it indicated a pretty good state of affairs in that some supposedly very good work got rejected just because there were confidence issues in the long term reliability of the developer (ie, Con could not work on the what he produced full time and drop everything to fix any bugs discovered later) and that the code itself was difficult to thoroughly review and merge with what was current by the time he submitted it.

Although as with any human interaction Linus seems to be involved in he probably could have handled it better on a personal level :)

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

[dfghjk]

No, it shouldn't.

Repost

[jovius]

http://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered

Compiler warning

[JDG1980]

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.

Re:Compiler warning

[Anonymous Coward]

Not at the time because of the parenthesis around "current->uid = 0". Actually they someone noted: http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0647.html

(current->uid = 0)

No idea as of today's gcc though ...

Re:Compiler warning

[Anonymous Coward]

Yes, GCC will generally warn IF the assignment is the ONLY expression within an if statement. Putting an assignment after an AND or an OR is often desirable to utilize lazy-evaluation, so it shouldn't throw a warning... that'd just be an annoying/useless warning.

Re:Compiler warning

[Pembers]

gcc does warn about it, but the extra parantheses around the assignment suppress the warning. It's part of the language specification, so the compiler can't forbid it - at least not by default.

Re:Compiler warning

[Anonymous Coward]

It does however the attacker had enclosed it in parentheses preventing the warning. This was at the time though. Perhaps GCC has gotten smarter regarding this?

SubjectsInCommentsAreStupid

[lesincompetent]

It's FOIA time!

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

[Waffle Iron]

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

[Anonymous Coward]

look at this wrong opinion right here.

look at it.

Calm down

[Anonymous Coward]

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:Calm down

[Anonymous Coward]

Would you react the same way if it said "could it have been a Chinese attack?"

Personally, yes. Any kind of speculation on the source of the attack without evidence is pointless 10 years later, and the only reason to even mention one is to yank everyone's chain. There was no good reason for Ed Felten to end the article with that sentence, other than to raise eyebrows and get more page views.

Re:Calm down

[Xtifr]

No the reason to mention the NSA is that the NSA's hackery has been all over the news recently, so it's an obvious leap that many people would have made if he hadn't mentioned it. In fact, for all we know (reporting being what it is), it was a direct response to the question, "do you think the NSA is responsible?"

Re:That was then, this is now

[Anonymous Coward]

here No need to thank me.

== stupid language construct.

[Anonymous Coward]

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

Witch Hunters and good laughs

[Anonymous Coward]

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!

Re:Witch Hunters and good laughs

[Jaws]

In Iron sky, the Nazis obviously had no programming skills, things were hardwired:

http://felixpearce.files.wordpress.com/2012/11/richter_and_the_computer-copy_resized.jpg

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

[0123456]

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

[Impy the Impiuos Imp]

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.

CVS exploit

[Anonymous Coward]

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.

Dave Miller

[Anonymous Coward]

My theory is Dave Miller is a spy.

He "claims" he didn't make the kernel change in 2003 but his name was on the changelog.
He is the primary networking maintainer (a perfect position to sneak in other backdoors)
He is part of the GCC steering committee (another place where backdoors and vulnerabilities would be useful)

He even looks a little shifty :-) http://en.wikipedia.org/wiki/David_S._Miller

was careful enough to notice that that

[SJester]

"the Linux team was careful enough to notice that that this code was in the CVS repository" Do I win a prize for being careful enough to notice that that?

Re:was careful enough to notice that that

[tippe]

Maybe you should. I hadn't noticed that that "that that" was incorrect. That that was a good catch!

Re:was careful enough to notice that that

[TangoMargarine]

Is that that 'that' that that 'that' refers to?

(And ending on a dangling preposition! :D )

Re:was careful enough to notice that that

[idontgno]

That that is is that that is not is not is that it it is.

On the other hand, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo..

Re:OMG enough: 2 = infinity

[stanlyb]

Yep, if no one has seen any aliens, you could assume that they don't exist. BUT, if you see even one alien, you could say that they are everywhere.
Simple math man, 2 = infinity .

Bruce Schneier's entire point

[ThatsNotPudding]

All the criminal activity the NSA has done and continues to do has done nothing but made the entire hardware and software structure of the Internet vulnerable, paving a smooth, superhighway to everyone else in the world that wishes to either destroy modern society or simply steal money from the 99%.

The petard the NSA and Western World will be hoisted upon is one of their own making. (Cylons 1:15)

Re:Bruce Schneier's entire point

[evilviper]

All the criminal activity the NSA has done and continues to do has done nothing but made the entire hardware and software structure of the Internet vulnerable

The NSA didn't make the world vulnerable. They just jumped-in and said "ME TOO!".

Re:OMG enough: 2 = infinity

[Anonymous Coward]

There's no such thing as 2

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

[phantomfive]

I use it all the time in code like:

if(( bytesWritten = write(sock, buf, bytesRemaining)) == ERROR) {

It's an ok to deal with the fact that the BSD socket API is overly verbose and a pain to deal with. The last time I made a mistake accidentally doing = instead of == was a long, long time ago, though. So I'm not sure it's a real problem.

Set the conspiracy theories aside for a moment...

[damn_registrars]

Even if the code had been accepted and committed, it would have been some time before it would have started rolling out into systems. How many people do you know who consistently run the latest Linux kernel? The most popular distros are generally (at least) a few months behind on adopting the latest kernel, so even if this was committed next week it would have likely not shown up in widespread use until the middle of next year at the earliest.

And beyond that, the users that use Linux are likely far less interesting to the NSA than they like to tell themselves to be. Enemies of the state don't generally have an interest in running anything other than windows (which they often steal, so the cost is irrelevant).

GayDicksInYourButt

[Anonymous Coward]

Hi there!

"Who" is not the point.

[steelfood]

If it was the NSA, it'd be hard to trace now. Especially as this is going back to 2003, prior to all this excitement. It doesn't matter. It didn't work, and the NSA is suspected of perpetrating more recent attacks at a different level in the chain.

But this example brings up a good point, which is how vulnurable C and C++ code is in general to obfuscation. It is a known security risk and attack vector, but programmers tend to gloss over it, mainly when they can't accept that they are just as capable of making mistakes as the next guy.

Re:That was then, this is now

[Anonymous Coward]

here No need to thank me.

I wasn't going to.

Re:OMG enough: 2 = infinity

[sneakyimp]

Am I the only one who is REALLY afraid of aliens trying to backdoor my cornhole?

More likely SCO

[Anonymous Coward]

Geez, wasn't this when the SCO Lawsuits 'R Us started? They are more likely to have been at fault here than the NSA. More like a bunch of wannabe half-ass hacks attempting to write a way to plant code than some other wild-ass theory.

Curses, foiled again

[BenSchuarmer]

and it would have worked too, if it hadn't been for those meddling kids.

Wait, this happened in 2003?

[damn_registrars]

Well if it happened in 2003, then we know it cannot possibly be the NSA. After all, we have been told repeatedly by the mainstream media and by reputable unbiased sites such as our beloved slashdot that the government was 1000% righteous and benevolent from 2001-2008 and only became evil after we elected a socialist anarchist fascist liberal hippie far left islamist atheist democratic dictator to the white house. So clearly, the NSA in 2003 could not have been behind an attempt to insert malicious code into the Linux kernel; and if they somehow were then real Americans had nothing to fear about it anyways!

But of course, they weren't behind it! They couldn't have done it!

Re:Wait, this happened in 2003?

[Anonymous Coward]

we have been told repeatedly by the mainstream media and by reputable unbiased sites such as our beloved slashdot that the government was 1000% righteous and benevolent from 2001-2008

I know you are being sarcastic, but you are also just making shit up. Stop the lying. The mainstream media, aside from a short window around 9/11, harassed the hell out of W the whole time he was in office, and slashdot wasn't a big fan either. No part of the government was immune to criticism when W was in charge of it all. The NSA was not on peoples' minds back then, but if they had been, the MSM and slashdot would have raised hell MORE because the President was W.

Seriously WTF man. Are you this intellectually dishonest all the time? shame on you.

Re:Wait, this happened in 2003?

[Anonymous Coward]

Wow...someone certainly earned his Obama Fan Club Secret Decoder Ring today.

Re:Wait, this happened in 2003?

[SleazyRidr]

Look, clearly you are mistaken somewhere. Obama is getting criticized for doing exactly what Bush did. We didn't like it when Bush did it, and we don't like it now, but we thought that Obama would at least try to stop it. Just because we're criticizing Obama doesn't mean we automatically like Bush, or think that McCain/Romney would be doing better.

Re:Wait, this happened in 2003?

[damn_registrars]

Just because we're criticizing Obama doesn't mean we automatically like Bush, or think that McCain/Romney would be doing better.

I see you're new here - or at least, your account is newer than this one. So you might not have been reading stories and comments here for very long. The truth of the matter though is that slashdot pushes a conservative agenda. Watch the front page for a week, and count up how many articles are plainly anti-Obama, anti-democrat, or anti-non-conservative. Then try to find even one that is critical of the GOP, conservatism in general, or any policy that is associated with their platform.

There is a very plain editorial stance here at slashdot, and it is prevalent all the way through.

Re:Wait, this happened in 2003?

[kermidge]

"There is a very plain editorial stance here at slashdot...."

Yup, there is. I lurked for a handful of years before registering, and, apart from the now missing "News for nerds. Stuff that matters." the only plain stance I can see is that there is no stance. Unless it involves one of several in-house contests: most subtle grammatical error hidden amidst the obvious ones in a submission; most oddly-framed responses to a poll; or the pool for length of time it takes for a complaint against a pay-walled link. There might also be a yearly raffle for the oddest "Ask Slashdot..." but I wouldn't swear to it.

uid = 0

[elistan]

So if one were to grep the source code for "uid = 0" today, I assume that any instances found are legit?

NSA, not likely

[seeker_1us]

Remember the NSA has worked to HARDEN linux, and even contributed the SElinux system.

Re:NSA, not likely

[davidbrit2]

As far as you know. (Spooky music goes here.)

Re:NSA, not likely

[SleazyRidr]

I could imagine that the NSA might create a super-secure system for themselves, yet release a sublty-hacked version for the public. This would then give them a slightly more focused area on which to spy (don't need to spy on the people who don't care about privacy/security cause you can just read their facebook.) I do start to worry about myself becoming a conspiracy theorist when I do that, but the more I hear the more I realise that shit isn't right.

Re:NSA, not likely

[marcosdumay]

I'd expect the NSA to at least require a key for a backdoor they create. Looks more like some random hacker's job.

Re:NSA, not likely

[Anonymous Coward]

I'd expect the NSA to at least require a key for a backdoor they create. Looks more like some random hacker's job.

Theo de Raadt did it to discredit Linux and in retaliation for the cancellation of project POSSE. He was hoping the resultant PR fest would allow him to snatch up all Linux developers to raise OpenBSD to the greatness it deserves while poking DARPA in the eye for cancelling the project. I thought everyone knew this...

Captcha: Origins - as in "Origins of the hack"

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

[Hognoxious]

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

A broken clock is right twice a day.

Unless you broke it by pulling the hands off.

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

[ais523]

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.

In gcc, you can do -Werror=parentheses if you want to make this an error rather than a warning.

Re:That was then, this is now

[Anonymous Coward]

I just say "no thanks" to Git.

front door

[Anonymous Coward]

why do you need bsckdoors, when linus (and others) are putting backdoors in the kernel and other parts of linux and opensource?

to start, how about the mess of a random number generator for starts, that linus is actively defending that is proven insecure and faulty?

he could fix it in the time he has spent defending it. why linus? have you recieved any letters from various agencies that is stopping you?

how about the openssl mess.

why is red hat dragging its feet about updating the library leaving tls and other things broken for years on all related distros?

i am a super fan of open source and linux, but is exactly as a fan that i am outraged by the state of security and the way the leaders of the open source community is pretending there are no problems across the linux community.

i know, the flaims will follow for such statements, and i might point out you are just making my point. flaim me, but i ask that you spend 30 mins reviewing the state of some code in some opensource project (or at least try to review if you if you lack the skills).

too much trust is being put in too few hands in open source. as open source has gotten more popular, the code base has exploded across the open source landscape. who is auditing the security over all?

Holes are used more than back-doors

[Anonymous Coward]

The main method of attack by NSA programmers who work in ALL the big open-source projects is to ensure poor coding methods are used, so that simply 'overflow' or memory management fails allow rogue code to be executed, pulling in the NSA payload onto the user's system.

The problem with a 'back-door' is that it is visible code with an obvious purpose, and can potentially be traced back to the teams responsible. Exploitable code flaws, on the other hand, can be ignored as the 'expected' variability of code quality. A 'back-door' is a clear construction. A code flaw is a 'consequence' of the range of expected quality of coding as described by a 'Bell curve', and thus has plausible deniability.

Code libraries are the BIGGEST problem. Take Windows. Do you REALLY think a multi-billion dollar company like Microsoft could not have fixed its string-overflow issues. But such 'faults' form 50%+ of all purposely created NSA vectors.

Linux relies on a bunch of libraries, each of which is KNOWN to be buggy as hell when more obscure data packets are processed (like JPG files with exotic formats). Linux tends to ONLY perfect the commonly used paths. No-one using or deploying Linux has much of a clue what happens if rarely used functions of libraries are used.

How can this be fixed? It can't. Anyone who codes on a big project knows that even getting the core stuff good is a royal pain. The idea that comprehensive test data will be crafted for functionality present but almost never required is a JOKE. If security is an issue, all big software projects (commercial or open-source) MUST be considered to be highly compromised, and other methods used to protect against intrusion.

The NSA is thousands of times worse than even most of you informed types realise. It has a yearly budget running beyond tens of billions purely on the R+D side
alone (hardware has its own funding). The NSA expects EVERY major piece of software you use to be heavily compromised, so rogue datasets allow code injection. Owners of major software companies KNOW the NSA will have them set up for major jail time if they fail to co-operate. The USA is infinitely more ruthless than the Soviet Union ever was. And since co-operation does NOT usually mean 'back-doors', but the simple use of common libraries that the NSA has compromised, cooperation with the demands of the NSA causes few sleepless nights.

Slashdot pushes stories like this to make you look in the wrong direction. It is like when the mainstream media tells you that ONLY phones with GPS chips can be location tracked (a complete lie- it is a requirement under US law that ALL mobile phones have their locations continuously monitored by so-called cell-tower triangulation methods). Or when you are told your vehicles are exclusively tracked by cameras, when the vast majority of tracking is done by under-surface RFID readers reading the RFID chips that have been mandated for embedding in tires for years now. Or how the shills tell you to ignore the fact that Bill Gates personally oversees the NSA Xbox One Kinect spy project, the Common Core atrocity in US schools, and the inBloom full surveillance database of every child in the USA that he co-created with Fox News' owner, Rupert Murdoch (awww- all you thick sheeple thought Gates and Murdoch were on opposite sides- how cute).

Re: Holes are used more than back-doors

[Anonymous Coward]

Exactly!

Argumentum ad Wirthinem

[Hognoxious]

Personally if I was designing a language I'd ban the single = operator and use := for plain assignment

That must be wrong, Pascal does that!

bullshit more like

[Anonymous Coward]

More like p.r job for PC safety courtesy of nsa. One story says Linus jokes about a backdoor, another says- no chance we spotted the code, carry on thinking your safe from hackers or the government with open source. Truth is likelihood of backdoor in linux kernel is very high, in MS its a sure thing. Competitions of hidden malicious code surely won't inspire a whole generation of 15 year old spotty teenagers to learn this stuff, way quicker than those of us a bit older... ;)

Re:Set the conspiracy theories aside for a moment.

[Anonymous Coward]

And beyond that, the users that use Linux are likely far less interesting to the NSA than they like to tell themselves to be. Enemies of the state don't generally have an interest in running anything other than windows

You're making two false assumptions. The minor one is the latter, that enemies of the state generally all run windows. That's just a silly assumption. But even if that were true, the larger false assumption is more subtle: that the NSA is only interested in what "enemies of the state" are doing. The NSA is demonstrably interested in what everyone is doing. Maybe it's just data gathering in case John Q Citizen turns out at some future time to be an "enemy of the state". Maybe it's an arbitrariness in just what constitutes an "enemy of the state". After all, if the NSA is acting in (what they consider to be) the state's interests, then isn't an enemy of NSA also an enemy of the state? And we can see where that road leads...

Your alternative is no better.

[Anonymous Coward]

Whereas your view, if it could be someone else, then it can't be the NSA is no better.

Oh, and before you whine like a bitch "Where did I say it can't be the NSA?", where did they say it must be the NSA?

Roachie, Super Hacker

[Roachie]

I transpose '=' for '==' not infrequently.

Mind you, its not because I'm incompetent, but because its all part of my plan to root the world.

Underhanded C Contest

[KingofSpades]

I'm suprised that no one mentioned the Underhanded C Contest
http://underhanded.xcott.com/

Quoting their web site:
"The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil. "

Re:Underhanded C Contest

[Anonymous Coward]

this fails the innocence test

Who did it?

[Anonymous Coward]

Anonymous Coward did it.

Thank You!

[laing]

I remembered this incident when it occurred. Last month I spent an hour searching the Internet for any trace of it and came up empty. At the time I was taking an IT security course and I wanted to share the details of the incident with my classmates. Given recent events within the IT security community, this story seemed very relevant. I couldn't find anything at all so I eventually gave up.
Thank you for bringing this incident back to light.

incomplete question...

[Anonymous Coward]

"Have you stopped beating your wife YET ?

It happened in 2003?

[Anonymous Coward]

Then it WAS Bush's fault!

Wait4 it

[chair300]

My bad, I was just trying to contriubute to the linux code base securely.

It was Niklaus Wirth

[Latent Heat]

. . . getting back at the C-language community for the lame use of "=" as an assignment operator and allowing explicit state changes (assignments -- you still have function evaluation side effect to worry about) within condition tests.

Re:It was Niklaus Wirth

[LanceUppercut]

Well, firstly, in C it is allowable to use assignments (and other operators with side-effects) within any expression, not just inside "condition tests". Expression in condition tests do not receive any special treatment. Secondly, the whole purpose of expression statements in C is their side-effects, since the result of the full expression in such statement is always ignored. Taking that into account, it becomes obvious that prohibiting side-effects in C expressions would have made these expression completely unusable.

So vocal.

[basecastula]

It was you? Wasn't it?

Linus did it

[Anonymous Coward]

So that everyone would stop using CVS.

Typo Alert - It's Spelled "Felten" with two Es

[garnett]

Please correct the main post - you've got Ed Felten's name misspelled twice. See the cited blog post (https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-2003/), and Wikipedia's article on him (http://en.wikipedia.org/wiki/Ed_Felten). Apparently this misspelling happens often enough that Wikipedia redirects silently.

Thanks, folks.

cool story bro

[Anonymous Coward]

tell it again

Criminal Organizations

[fyngyrz]

Of course [...] a criminal organization would get the most benefit until the hole was found and fixed.

Yes. Government(s). That's what we're saying.

I tak responsibility

[Anonymous Coward]

I did it when I was there to pick up my prescriptions....... Get it???...

Wah Wah Wah Waaaaaaaah.

Re:OMG enough: 2 = infinity

[Anonymous Coward]

Yes. The rest of us wish they would just so you'd shut up about it.

j/k

Good job on the summary

[SigmundFloyd]

It contains informative links that aren't in TFA. Well done.

News for nerds, stuff that mattered nine years ago

[GrumpySteen]

*sigh*

Re:Set the conspiracy theories aside for a moment.

[kermidge]

"And beyond that, the users that use Linux are likely far less interesting to the NSA...."

While Linux users are not particularly interesting to anyone (except an advertiser or demographer, e.g.), having a back door giving root would be handy should an individual end-user become a person of interest.

The attractive targets are servers, or more specifically machines used to run various networks, I should think. I doubt that a worthy enemy of the state would be conducting his core affairs on a machine connected to the 'Net; I would imagine that any machine under his control connected to the Internet would be part of the execution of some ploy and therefore backstopped and made anonymous (by cutouts and such) to a fare-thee-well.

Wonder who it was no longer!

[Anonymous Coward]

https://www.youtube.com/watch?v=a43kowi2ncI

Re:Set the conspiracy theories aside for a moment.

[CountZer0]

And beyond that, the users that use Linux are likely far less interesting to the NSA than they like to tell themselves to be.

Every large financial institution in the country uses Linux on their servers.

Linux on the desktop? Mostly geeks. Linux on servers? Everywhere you look! Of course, that's also where the fun data that the NSA cares about also happens to be, on the servers...

The bigger question is...

[Anonymous Coward]

How crappy was Bitlocker that people preferred to CVS instead?

Or, is it like choosing MS's laughable 'team' tools over Git or hg? There are always a few dumb-asses that do this.

I remember this discussed at the time.

[Truth_Quark]

And this comment amused me:

Linus isn't just a good C programmer. After half a decade of watching him catch stuff like this in just his public LKML messages, I'm convinced he would have seen this if he were reading braille hardcopy of it from across the room while drunk.