Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Backdoor Attempt of 2003 (2013)

freedom-to-tinker.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: The Linux Backdoor Attempt of 2003 (2013)

#91

Post by NelsonMinar »

yyyk wrote: post #74

This is an obvious backdoor attempt, as the code doesn't make sense otherwise. Yet, the attempt was far too unsubtle and underspecific for agencies such as the NSA. The payoff was low compared to the possibilities - local privilege escalations were a dime-a-dozen. Worse, agencies such as the NSA have two missions: offence and defence. Adding in backdoors helps the offensive mission, but hurts the defensive mission, s…

The NSA used to have a defensive mission. They fully compromised their ability to do that by subverting the security of American products time and time again. The Shadow Brokers disclosure alone has completely undermined any trust anyone in the industry has for the NSA.

Re: The Linux Backdoor Attempt of 2003 (2013)

#92

Post by kazinator »

perihelions wrote: post #52
cyphar wrote: post #25

Earlier quoted context omitted.

These days it'd be harder to write code which is "easy to overlook" -- the innocent version would be something like if (/* ... */ || current_euid() == GLOBAL_ROOT_KUID) But the "backdoor" version would fail to compile (current_euid() is a macro but it's written to not be a permitted lvalue). You would need to write something more obvious like the following (and kernel devs would go "huh?" upon seeing the usage of cur…

"(current_euid() is a macro but it's written to not be a permitted lvalue)" I'm not an expert at C. I followed up on this kernel macro out of curiosity, and it was a confusing learning experience because it turns out the forbidden assignment ({ x; }) = y; is silently permitted by GCC (for example, with -Wall --std={c99,c11,c18}), and does actually assign x=y. Even though that's expressly prohibited by the C standard…

What you quoted:

    ({ x; }) = y;
isn't ISO C syntax; it's a GNU extension.

-Wpedantic diagnoses ISO C syntax errors, even if they are GNU extensions.

Re: The Linux Backdoor Attempt of 2003 (2013)

#93

Post by ed25519FUUU »

db48x wrote: post #80
hmottestad wrote: post #2

I admit that I read the code and completely overlooked the single equals sign. Makes me wonder why it would be so easy to change the userid. Shouldn’t there be some safeguards in place to stop the userid from being updated from unsafe places.

Absolutely. This is an example of the poor design of the C language. Other languages that were around at the time C was created choose `:=` as assignment and `=` for equality tests, making this type of typo quite impossible. Common Lisp makes the Hamming distance even larger; equality tests are written as `(eq foo bar)`, while changing a value is `(setf foo bar)`. Common Lisp may have features which are undesirable i…

:= Still seems easy to overlook at a cursory glance.

Re: The Linux Backdoor Attempt of 2003 (2013)

#94

Post by grishka »

DC-3 wrote: post #53
lqet wrote: post #47

Earlier quoted context omitted.

AFAIK only external and static variables are default initialized in C. For all other variables, the default value is undefined, so 0 is as good a choice as any other here.

Except that uninitialised memory is substantially more likely to be 0 than any other value.

Except sometimes it is not and forgetting to initialize a variable in C/C++ leads to very insidious bugs that no one can reliably reproduce.

Re: The Linux Backdoor Attempt of 2003 (2013)

#95

Post by grishka »

_urga wrote: post #6

Something as important as "uid" should be "const".

There are legitimate reasons to change the uid at runtime. For example, some server software starts as root and then drops to a less-privileged user. Android relies on this too, zygote, the fully-initialized "blank" runtime process, runs as root and gets forked and changes uid to the corresponding unprivileged user whenever an app is launched.

Re: The Linux Backdoor Attempt of 2003 (2013)

#96

Post by tsbinz »

kazinator wrote: post #89
tsbinz wrote: post #87

Earlier quoted context omitted.

I would be careful with statements like this. New compilers do NOT make this a warning/error, see for example https://godbolt.org/z/5zzz33 Note that there are parentheses around the assignment which the compiler takes as an indication that this is intentional. Also note that the parentheses are required because without them the precedence would be wrong.

Since the parentheses are required due to precedence, then they are not there to show "I intend this assignment to happen". That would have to be: if ((options == (__WCLONE|__WALL)) && ((current->uid = 0))) As an aside, note that this particular case also has the problem that the assignment expression makes the entire test expression false, which is suspicious. If an assignment expression occurs in the controlling ex…

I'm not saying that a compiler shouldn't flag this. I'm just saying that current compilers don't.

I'd guess that static analysis tools do flag it, but haven't checked.

Re: The Linux Backdoor Attempt of 2003 (2013)

#97

Post by jhardy54 »

mercer wrote: post #85
GuB-42 wrote: post #60

Earlier quoted context omitted.

It is not so easy, it is a contest, and they show you the winners. And if you look at the "Scoring and Extra Points" section of http://underhanded-c.org/_page_id_5.html you will notice that it checks most of the boxes. It is short, errors based on human perception (here = vs ==) are good enough, it is innocent looking under syntax highlighting, is is not platform dependent, and it even passes the "irony" check. It is…

now I'm wondering if syntax highlighting shouldn't somehow make an assignment inside an if statement (and the variants) a bright red, or something like that.

You may be interested in linters.

Re: The Linux Backdoor Attempt of 2003 (2013)

#98

Post by coldpie »

reactchain wrote: post #75

What are the chances major projects we use today aren't backdoored similarly? It's so easy to do and so hard to detect.

> What are the chances major projects we use today aren't backdoored similarly?

Basically zero. There is no such thing as computer security in 2020.

Re: The Linux Backdoor Attempt of 2003 (2013)

#99

Post by kazinator »

ed25519FUUU wrote: post #93
db48x wrote: post #80

Earlier quoted context omitted.

Absolutely. This is an example of the poor design of the C language. Other languages that were around at the time C was created choose `:=` as assignment and `=` for equality tests, making this type of typo quite impossible. Common Lisp makes the Hamming distance even larger; equality tests are written as `(eq foo bar)`, while changing a value is `(setf foo bar)`. Common Lisp may have features which are undesirable i…

:= Still seems easy to overlook at a cursory glance.

What db48x neglected to mention is that some of those languages also featured assignment as strictly a statement; it could not be a subexpression. As in:

   fun(x := 42);   (* syntax error in Pascal *)

   x := 42;  (* OK *)

   x = 42; (* hopefully a statement with no effect warning *)
If assignment is a statement, it's possible to use the same token. Classic BASIC:

   10 X = 5
   20 IF X = 5 GOTO 10
This doesn't cause the C problem of mistaken assignment in place of a test, so it's rather ironic that C managed to shoot itself in the foot in spite of dedicating twice the number of tokens.

Re: The Linux Backdoor Attempt of 2003 (2013)

#100

Post by xxpor »

NelsonMinar wrote: post #91
yyyk wrote: post #74

This is an obvious backdoor attempt, as the code doesn't make sense otherwise. Yet, the attempt was far too unsubtle and underspecific for agencies such as the NSA. The payoff was low compared to the possibilities - local privilege escalations were a dime-a-dozen. Worse, agencies such as the NSA have two missions: offence and defence. Adding in backdoors helps the offensive mission, but hurts the defensive mission, s…

The NSA used to have a defensive mission. They fully compromised their ability to do that by subverting the security of American products time and time again. The Shadow Brokers disclosure alone has completely undermined any trust anyone in the industry has for the NSA.

They still get to have input into FIPS whether anybody likes it or not
Post reply on HN