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.
The Linux Backdoor Attempt of 2003 (2013)
41–50 of 144 posts
Re: The Linux Backdoor Attempt of 2003 (2013)
#42I'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.
could do this instead, right?
do {
*dst = *src;
*dst++;
*src++;
} while(*dst);Re: The Linux Backdoor Attempt of 2003 (2013)
#43A 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.
>and, in this case, a good way to hide something malicious as an accident
The number could've been 2342 and the backdoor would've worked exactly the same way.
Re: The Linux Backdoor Attempt of 2003 (2013)
#44There 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.
Parent said "in the source code" not "in the Linux source code". Given the abysmal standards of security everywhere, it's quite logical thing to assume that many parties have backdoors scattered around various OSes. A tempting target with such multiplicative benefits.
I don't think it's a paranoid question and I don't think it's even a question. It's a natural assumption and I'd demand exceptionally good evidence to challenge that.
Points for Linux for its openness, people will probably catch some of these.
Re: The Linux Backdoor Attempt of 2003 (2013)
#45There 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?
This particular glitch was inserted via an attack on the BitKeeper repository. (EDIT: it was actually a CVS mirror of the repo.)
But for the normal contribution flow, code review isn't the only safeguard. There's also a deterrent in that should a backdoor be inserted via a contribution that went through the normal process, an audit trail exists. If the backdoor is later discovered, there would be reputation harm to the contributor.
Depending on how much an open source project knows about its contributors, it may be more or less difficult to track down a culprit, but in any case the audit trail makes such attacks more complicated.
Re: The Linux Backdoor Attempt of 2003 (2013)
#46Earlier quoted context omitted.
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.
could do this instead, right? do { *dst = *src; *dst++; *src++; } while(*dst);
[deleted]
Re: The Linux Backdoor Attempt of 2003 (2013)
#47A 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.
Re: The Linux Backdoor Attempt of 2003 (2013)
#48This 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…
> non-antediluvian C compiler Contrary to popular opinion, Noah's C compiler was actually highly advanced, but he only brought one copy on the ark with him. No backups, and less than ideal storage conditions... you can guess what happened next. A triceratops ate the parchment tape containing the only copy of Noah CC, and Noah threw the offending triceratops off the Ark, because in his rage, he thought "I have a spare…
Is that an ancient predecessor to HolyC?
Re: The Linux Backdoor Attempt of 2003 (2013)
#49I'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.
However they do not emit a warning if the assignment is parenthesized, like in the exploit. I think static analysis tools are the same, they would be way too chatty if they emitted warning for a parenthesized assignment.
Static analysis already has way too many false positives as it stands. For a well maintained code base the rate can easily be 100% false positives, which gets annoying after some time.
Re: The Linux Backdoor Attempt of 2003 (2013)
#50Earlier quoted context omitted.
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.
could do this instead, right? do { *dst = *src; *dst++; *src++; } while(*dst);
I think you are not copying the terminating nul character.