The Linux Backdoor Attempt of 2003 (2013)
freedom-to-tinker.com
The Linux Backdoor Attempt of 2003 (2013)
1–10 of 144 posts
Re: The Linux Backdoor Attempt of 2003 (2013)
#2I 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.
Re: The Linux Backdoor Attempt of 2003 (2013)
#3If curious see also
2018 https://news.ycombinator.com/item?id=18173173
Discussed at the time (of the article): https://news.ycombinator.com/item?id=6520678
Re: The Linux Backdoor Attempt of 2003 (2013)
#4I think that this might be an typo or at least it has plausible deniability. I have changed my coding style to always put constant on left side just to avoid such an error (such typo gave me a few days of debugging multithreaded code and I have just said "Never again!!" :D)
Re: The Linux Backdoor Attempt of 2003 (2013)
#5I think code like this shouldn't even compile like in other languages
>Operator '&&' cannot be applied to operands of type 'bool' and 'int'
Re: The Linux Backdoor Attempt of 2003 (2013)
#6Something as important as "uid" should be "const".
Re: The Linux Backdoor Attempt of 2003 (2013)
#7Was this a backdoor or not? Following the comments on the article and previous posts here on HN it seems the jury is out AFAICS.
The crucial question to me seems to be if this condition:
options == (__WCLONE|__WALL)
Re: The Linux Backdoor Attempt of 2003 (2013)
#8From 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.
Re: The Linux Backdoor Attempt of 2003 (2013)
#9Was this a backdoor or not? Following the comments on the article and previous posts here on HN it seems the jury is out AFAICS. The crucial question to me seems to be if this condition: options == (__WCLONE|__WALL) can be willfully introduced by a bad actor, and otherwise never really occur. Unfortunately I don't know this (not familiar with Linux development) but herein lies the answer it would seem.
Definitely a door for a local privilege escalation. But since it's so obvious, we may call it a second front door.
Re: The Linux Backdoor Attempt of 2003 (2013)
#10This 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 with -Werror. Ditto clang 9. (Look at me giving version numbers as if this were recent. Any non-antediluvian C compiler worth using will do the same.) My point is, any reasonable build would at least pop up some errors for this, making it appear amateurish to me.