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

31–40 of 144 posts

Re: The Linux Backdoor Attempt of 2003 (2013)

#31

Post by roenxi »

WhiteSage wrote: post #8

From the article comment section: > this is not a mistake. > Assume that the coder meant == 0 what is he trying to enforce. If these 2 bits (_WCLONE and _WALL) are set and your are root then the call is invalid. The bit combination is harmless (setting WALL implies WCLONE [...]), and why would you forbid it for root only.

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

I'll attach this here for people who read the article too quickly and think it may, somehow, have been a bug. This code was a very deliberate attack.

Re: The Linux Backdoor Attempt of 2003 (2013)

#32

Post by brobdingnagians »

IshKebab wrote: post #28
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?

Because of selection bias - if they had chosen something less subtle then we wouldn't be talking about it.

Maybe it is a smoke screen, put in something likely to be found and something that won't. Everyone pats themselves on the back for finding the obvious one...

Re: The Linux Backdoor Attempt of 2003 (2013)

#33

Post by gvjddbnvdrbv »

brobdingnagians wrote: post #32
IshKebab wrote: post #28

Earlier quoted context omitted.

Because of selection bias - if they had chosen something less subtle then we wouldn't be talking about it.

Maybe it is a smoke screen, put in something likely to be found and something that won't. Everyone pats themselves on the back for finding the obvious one...

This seems highly likely.

Re: The Linux Backdoor Attempt of 2003 (2013)

#34

Post by gonzo41 »

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?

A classic paranoid security question.

The ace in Linux's pocket is that you're free to read it all. That can't be said for Apple, and Microsoft or any of the OS's running switches and hubs out there. Let alone all the server side cloud code.

Re: The Linux Backdoor Attempt of 2003 (2013)

#35

Post by nurettin »

phh wrote: post #23
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 don't think gcc 9 was available in 2003.

We had gcc3, but some people were still stuck with redhat's patched 2.96 (which was officially 2.95 + some security patches)

Re: The Linux Backdoor Attempt of 2003 (2013)

#36

Post by kubanczyk »

IshKebab wrote: post #28
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?

Because of selection bias - if they had chosen something less subtle then we wouldn't be talking about it.

You've probably meant: if they had chosen something much subtler we wouldn't be talking about it.

Re: The Linux Backdoor Attempt of 2003 (2013)

#38

Post by rocqua »

blauditore wrote: post #37

I'm curious, wouldn't this also be caught by static code analysis tools, at least today? An assigment inside an if condition is both, most likely a mistake, and fairly easy to detect automatically.

I would guess this is part of the reason why most modern compilers will indeed emit a warning about assignment within if, for, and while - branch checks.

At the same time, the standard implementation of strcpy is:

    while((*dst++ = *src++));
which has a legitimate reason for doing assignment inside the while condition. Then again, one could argue that the above code is 'too clever'. And I would probably agree.

Re: The Linux Backdoor Attempt of 2003 (2013)

#40

Post by eru »

gitgud wrote: post #39

Has this happened since the source-control was changed to git? I imagine it would be almost impossible to break into Linus Torvald's git server amend previous commits, considering each one's hashed on the previous commits...

If you can break SHA1, that task would be easier.
Post reply on HN