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

81–90 of 144 posts

Re: The Linux Backdoor Attempt of 2003 (2013)

#81

Post by db48x »

Cthulhu_ wrote: post #63
eru wrote: post #40

Earlier quoted context omitted.

If you can break SHA1, that task would be easier.

SHA1 is close to being broken, but it's not there yet, and Git will be migrating to a better algorithm. That said, if you could rewrite an older commit, the change would only be applied in a fresh clone, right?

Even if you could break SHA1, it's unlikely that your replacement source code would look like it was human-written. Instead, it's going to look like human-written source code containing kilobytes or megabytes of random-looking comments. The comments will only be there to change the hash of the new content back to the hash of the original content. It's not going to be subtle at all.

Re: The Linux Backdoor Attempt of 2003 (2013)

#82

Post by yyyk »

badRNG wrote: post #78
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…

> 2) It was a warning shot from some Western agency meaning "tighten up your security". That's an interesting theory that'd certainly make for a powerful message. Has anything like that been done before or is there any precedence for Western agencies to do these sorts of things covertly?

I can't point to any evidence, but two things to note:

A) Even on HN the temptation has come up. e.g. some comments in posts about ransomware make a similar argument for transparently damaging and self-serving actions. Three letter agencies with much more power and ability probably had people making the same arguments.

B) The payoff was extremely low compared to the possibilities. Either whomever did this was unaware of the possibilities or not really interested in a major hack. Perhaps the idea was that if this actually works, the damage isn't so big, aside from embarrassing the Linux kernel team, and when the team noticed they'd tighten up.

Re: The Linux Backdoor Attempt of 2003 (2013)

#83

Post by fnord77 »

lqet wrote: post #47
davidhyde wrote: post #41

A uid of 0 being root is just such a bad idea to begin with because 0 is a default value of so many data types. It’s an accident waiting to happen and, in this case, a good way to hide something malicious as an accident.

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.

if you use malloc, yes. calloc will initialize the variables

Re: The Linux Backdoor Attempt of 2003 (2013)

#84

Post by tenebrisalietum »

Cthulhu_ wrote: post #66
aborsy wrote: post #12

There should be safe guards against such errors. Even with approval, the reviewer may not notice it. Which brings up the question: how many more root-based backdoors are there now in the source code?

Unfortunately in C and its derivatives, the safeguards would have to be external tools (static analysis, linters); it's a perfectly valid statement in code. I wouldn't mind if languages simply mark assignments in conditions as errors. It's clever code, but clever code should be avoided in critical systems. And in general, I guess.

Assignments in conditions can sometimes be useful and lend clarity, if it makes sense for the assignment to "fail".

For the rough, rough example the below is probably not too clever.

`if (!(my_socket=new_socket(inet_addr)) { fail(); }`

Re: The Linux Backdoor Attempt of 2003 (2013)

#85

Post by mercer »

GuB-42 wrote: post #60
londons_explore wrote: post #16

The underhanded C contest shows it is so easy to insert backdoors into C code that even someone staring at the code for a while wouldn't find. So why did this attacker choose such an obvious 'typo' rather than a subtle flaw in a large patch set?

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.

Re: The Linux Backdoor Attempt of 2003 (2013)

#86

Post by dzdt »

sslalready wrote: post #79
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…

If memory serves me right the CVS bug was originally discovered and exploited by a member of an infamous file sharing site. After descriptions(?) of that bug were leaked in underground circles, an east European hacker wrote up his own exploit for it. This second exploit was eventually traded for hatorihanzo.c, a kernel exploit, which was also a 0-day at the time. The recipient of the hatorihanzo.c then tried to backd…

This sounds like a very interesting tale. Are there more details written somewhere? How close to first-person is your source of information?

Re: The Linux Backdoor Attempt of 2003 (2013)

#87

Post by tsbinz »

msla wrote: post #10

This is something C linters have been catching probably since there have been C linters, either from looking for that specific pattern (a lone equals sign in a conditional) or by "inventing" the notion of a boolean type long before C had one and then pretending that only comparison operators had such a type. Needless to say, the better class of compiler catches this fine. gcc 9 does with -Wall and makes it an error w…

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.

Re: The Linux Backdoor Attempt of 2003 (2013)

#88

Post by tsbinz »

GuB-42 wrote: post #67
widforss wrote: post #65

Won't gcc complain if you assign a variable within an if-statement?

Not if you surround the expression with extra parenthesis. And that's what they did here. Assignments in if-statement can be useful, and that's how you prevent the compiler from complaining. That warning is intended for honest mistakes, not to catch backdoors.

The parentheses here aren't actually "extra", without them the meaning would change - since && binds tighter than = without the parentheses the left hand side of = would not be an lvalue and compilation would fail.

Re: The Linux Backdoor Attempt of 2003 (2013)

#89

Post by kazinator »

tsbinz wrote: post #87
msla wrote: post #10

This is something C linters have been catching probably since there have been C linters, either from looking for that specific pattern (a lone equals sign in a conditional) or by "inventing" the notion of a boolean type long before C had one and then pretending that only comparison operators had such a type. Needless to say, the better class of compiler catches this fine. gcc 9 does with -Wall and makes it an error w…

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 expression of a selection or iteration statement, such that the entire expression is always true or false as a result, that should probably be warned about no matter how many parentheses have been heaped on to the assignment.

Re: The Linux Backdoor Attempt of 2003 (2013)

#90

Post by kazinator »

simias wrote: post #29
mikkom wrote: post #27

Earlier quoted context omitted.

This is also very relevant comment: > In addition, parentheses were not required for the final comparison. This was done to prevent compiler warnings. This looks deliberate.

I would put parentheses here, I never like mixing logical operators with other types (or even different types of logical operators). While it's of course entirely redundant here, it also makes the code easier to read IMO. I think the parent's point is more convincing: why make this check only for root in the first place?

The parentheses are required if == is changed to =.

== has a higher precedence than &&, but = has a lower precedence.

   a = b && c && d
means

   a = (b && c && d)
Post reply on HN