Leading items

The brk() vulnerability

It has been disclosed that the compromise of the Debian Project's servers was made possible, in part, by a previously unpatched vulnerability in the kernel's memory management code. For the curious, this article describes how that vulnerability works, and what is required to exploit it. We'll also look at how it could have remained unfixed for months.

Process memory
0x00000000-0x08047FFF Unmapped area
0x08048000-0x08?????? Program text
0x08??????- Named memory and heap
0x40000000-0x4??????? Shared libraries, shared memory segments
0x4???????-0xbfffcfff Unmapped area
0xbfffd000-0xc0000000 Stack

The kernel organizes a process's memory in a way vaguely similar to the diagram at the right. The addresses shown there correspond to the default ia-32 implementation. This picture has been simplified somewhat, but it conveys the basic idea. The real picture on a specific system can be had by running "cat /proc/self/maps".

The bulk of the memory used by a program for its variables and heap storage is found in the section marked "named memory and heap" in the diagram. This memory area is initially made large enough to hold the static variables created by the program, but, as soon as more memory is required (to satisfy malloc() calls, perhaps) that region of memory must be expanded. Since the beginning, Unix-like systems have provided a system call (named brk()) which can be used to change the size of the heap area. The caller simply passes in the virtual address indicating where the new "break point" should be set, and the area is expanded or contracted as need be.

Back in September, Andrew Morton noticed that no sort of bounds checking was being applied to the address passed to brk(). In theory, this omission means that a process could request an arbitrarily large heap area. In practice, most programs would not get that far. The kernel does not allow virtual memory areas to overlap each other, so any expansion of the heap area that caused it to impinge upon the shared library areas starting at 0x40000000 would be rejected with an error. So it would appear that the lack of bounds checking was never that serious of a problem; all it could do is allow a user to set up some huge page tables.

Obviously, the situation is worse than that. The memory layout diagram is missing one important area; on ia-32 systems, the kernel itself is mapped in starting at 0xc0000000 - right above the process stack area. Processes normally do not have any access to that part of memory, of course. But, as it turns out, if you can convince brk() to expand your heap area up into the kernel's address range, you have direct access to the kernel code and data areas. At that point, the integrity of the system is lost.

The key to cracking the system is changing the process memory layout so that the heap area can be expanded into the kernel's space. You cannot easily do that with a normal C program, but, with a bit of assembly trickery things become easier. A proof of concept exploit has already been posted to Bugtraq, so one can see how it is done. It is really a matter of (1) moving the program origin up into the highest part of virtual memory, where the stack usually lives, and (2) shorting out the C library's startup code which sets up the address space in the first part. Once you do that, an unpatched system will happily expand your heap area into kernel space.

So, as the Debian Project learned at great cost, this little omission in the implementation of the brk() system call is fully usable for a complete local root exploit.

There have been a lot of questions about how such a vulnerability could remain unfixed for so long. In fact, it was patched in the 2.6.0-test series almost as soon as it was found. The fix also went to Marcelo Tosatti, the 2.4 maintainer, but it was too late for the 2.4.22 release, which happened on August 25. So the fix was merged into 2.4.23-pre7, which came out on October 9. The current 2.4.23 kernel is not vulnerable - but that was too late to help Debian.

The real problem, of course, is that nobody realized the severity of this bug. Had the kernel developers understood that current kernels were vulnerable to this sort of attack, the alert would have gone out and the various distributors would have sent out the usual set of updates. But this patch was just one of over 2000 patches merged by Linus in September. It would seem that it simply became part of the stream of fixes, and nobody looked at it particularly closely.

Except, of course, somebody did. Chances are, the posting of this fix drew an attacker's attention to the brk() code. With a bit of effort, the exploit got written, and now thousands or millions of systems are at risk.

What the kernel (along with most other projects) needs is more friendly eyes looking for this sort of problem. We do reasonably well, in that most vulnerabilities are found and fixed by the good guys before they can be exploited. There are cases where that doesn't happen, however, and the brk() bug was one of them. Security auditing is hard work, and usually unrewarding. But it would have been nice if somebody had looked hard enough at this problem to raise the alarm.

Comments (34 posted)

Wind River's change of heart

You win some, you lose some. While the free software community has lost an ally (by some peoples' reckoning, anyway) with the defection of SCO, Wind River seems to be coming around, at least to some degree. Until recently, the company had been fairly critical of the GPL and Linux as an embedded solution. The company surprised many in October when the announcement went out that Wind River would be providing tools for Linux development.

This week, Wind River upped the ante with the announcements that it would be joining two open source industry groups, the Eclipse Consortium and the Open Source Development Labs (OSDL). Wind River is joining OSDL to participate in OSDL's Carrier Grade Linux (CGL) Working Group, and focusing on embedded tools that are compatible with the Eclipse framework.

We spoke with Michel Genard, general manager of Wind River's Hardware Assisted and Stand-alone Tools product division about the company's change of heart. Why has Wind River changed its tune with regards to Linux? Genard first explained that Wind River's previous stance towards Linux and the GPL was based in part on fear.

Dave Fraser, Wind River's group vice president of products acknowledged in an interview with eWeek that Wind River had backed the wrong horse in trying to supplant Linux with a BSD-derived solution:

Being the Betamax of embedded OSes can be painful. According to the company's SEC filings, its revenue peaked in its 2001 fiscal year at almost $438 million, dropping to $351 million in 2002 and $249 million in 2003. (Wind River's fiscal year begins in April of the previous year.) Wind River seems to be headed for a disappointing 2004 fiscal year as well, with revenue for the six months ending July 31, 2003 falling off by almost $31 million compared to the previous year. Wind River also notes in recent SEC filings that open source may be more popular "where our customer's budget constraints may make such software more appealing than Wind River products for their initial project development."

Recent changes in management also help to ease Wind River's transition to a Linux-friendly company. Kenneth Klein has taken the CEO job after Tom St. Dennis resigned in late June. St. Dennis had been critical of Linux and the GPL, while Klein seems open to working with Linux and the free software community.

As Wind River tries to overcome its past missteps, it will likely face some skepticism. The company's past statements regarding the GPL aren't likely to be forgotten easily, nor the firing of Slackware's development team shortly after the BSDi acquisition.

More recently, Darl McBride has cited Wind River as one of the companies "on this side of the table as SCO is on." Though McBride seemed to be merely citing Wind River since the company had previously criticized the GPL, we asked Genard where Wind River stood on SCO's claims. Genard said Wind River has no position on SCO's claims that the GPL is invalid, but said that the suit was "a wake-up call for the customer."

There is also some concern that embedded companies are disregarding the GPL, so we asked Genard if Wind River would be working to educate their customers about their obligations when using GPL-licensed code in embedded devices. Genard said that, at the moment, they are only offering tools to develop Linux-based solutions and that the company isn't planning to "do any recommendation to the customer what to do with Linux."

One need not look too deeply to understand why Wind River has changed its attitude towards Linux. Its past strategy of dismissing embedded Linux simply wasn't working, and an ever-shrinking market share was probably not very appealing to Wind River's customers. Wind River is being squeezed on two sides in the embedded space. On one side is Linux, a robust solution that is royalty-free and extremely flexible. On the other side is Microsoft, which outguns Wind River by several orders of magnitude when it comes to dollars spent on marketing and R&D.

Whatever the reasons, it's good to see that a company can change its tune for the better. We hope that Wind River continues this process and becomes an active contributor to the free software community.

Comments (3 posted)

Jon Johansen returns to court

Things have been quiet enough on the DeCSS front that one might be forgiven for thinking that the issue had run its course. The software remains freely available on the net, and there are no high-profile DeCSS cases left in the U.S. We are now being treated to a reminder that the U.S. is far from alone when it comes to repressive legislation, however.

Jon Johansen is one of the original authors of the DeCSS code, which may be employed to play a DVD on a Linux system. The Motion Picture Association of America (MPAA), not content with its efforts to suppress any mention of the code in the U.S., went to the Norwegian economic crime authorities and asked that charges be pressed against Mr. Johansen in Norway. The agency (Økokrim) obliged, and Jon went to trial in 2002 for violations of Norway's anti-circumvention law. The court, however, decided that, if you buy a DVD with a film on it, you have bought the right to access that film. Jon Johansen was acquitted on all counts.

The Norwegian government appealed the ruling, and the new trial started on December 2. It is expected to last for eight days. Jon and his lawyers have expressed confidence that the appeal will come to the same conclusion as the original trial, but there is never any certainty when an issue goes to court. One can only hope that the appeals court will see reason and realize that it makes no sense to convict somebody for breaking into their own property.

Regardless of the outcome, however, the MPAA will have achieved an important goal. It has been made clear that, if you write the wrong sort of code, you can be arrested and threatened with jail. Even if the ultimate outcome is a complete acquittal, few people will want to avail themselves of the opportunity to learn how the justice system works in such a close way. The prosecution of hackers like Jon Johansen can only have a chilling effect on other developers, whether or not that prosecution is successful.

(See also: this IP Justice press release).

Comments (5 posted)

The GPL Is a License, not a Contract

[Editor's note: last week's article on GPL attacks drew some questions on just why the GPL cannot be enforced like a contract. We're pleased to announce that we have convinced Pamela Jones to expand on that issue for us.]

There has been considerable FUD of late asserting that, if a company inadvertently incorporates GPL code into its proprietary code, it can be forced to release its proprietary code under the GPL. This isn't new FUD. It's old FUD, but it is coming from some new sources. Even some attorneys have been saying this in the media and at various conferences. While it's not a crime to misunderstand the GPL, and it certainly isn't rare, it does arouse unnecessary fears about whether the GPL is safe to use or work with. Is it true? Can you lose your code this way? No, and the reason why hinges on the GPL being a license and not a contract.

A lot of the confusion about the GPL stems from this central issue: Is the GPL a license or a contract? The reason this issue matters is that contracts are enforced under contract law, which is done state by state, and there are certain necessary elements to qualify as a valid contract. Licenses, instead, are enforced under copyright law at the federal level. The penalties available are not the same.

Let's analyze and see how this all relates to the recent FUD. First of all, what is a license? A license is just a permission to do something you otherwise wouldn't be allowed to do. When I want to go fishing, for example, I have to get a fishing license from the local municipality. That's a license, as its name implies. But why? Why isn't it a contract? Because there are no further agreed-upon promises, no reciprocal obligations. It would be a contract if I said to the owner of a pond: if you give me a license to fish in this pond, I'll give you half of all the fish I catch. In that scenario, each of us has voluntarily entered into a kind of promise. We each give the other something of value, so if I get the license and then I don't give over half of all my catch of the day, the pond owner can sue me for not living up to the terms of the contract.

Eben Moglen, the Free Software Foundation's attorney, who is primarily responsible for enforcing the GPL, explains the difference between contracts and licenses like this:

Very clear, but what about the GPL? First, the name tells you what the authors intended: General Public License. It doesn't say "General Public Contract" or even "General Public License Contract". So they intended it to be a license, not a contract. Does it fit the definition? Professor Moglen:

Suppose a company really did mingle GPL code into a program with its own proprietary code and then distributed the merged product under a proprietary license or without living up to the terms of the GPL? Now what happens? What will the judge do now? Order the code released under the GPL over the wishes of the owner?

Stop and think. What happens if you violate the terms of a fishing license? For example, the license may restrict how much fish you can catch on a particular day or what kinds of fish you can keep, what sizes, etc. Suppose you violate the terms of the license. What happens? You lose your license to fish. There may be a fine to pay. That's essentially the same thing that happens under the GPL, except it's nicer, because the company gets to choose what it wishes to do under the terms of the GPL. If it still isn't resolved, and it goes to a judge, however, it's enforced as a violation of copyright law, not contract law. Here is Professor Moglen's explanation of what happens:

So when you read claims that the GPL is perhaps not enforceable because you don't sign it or click on a form, or because of a lack of privity, or because there is a lack of consideration, or some such, you'll know that the person misunderstood the GPL and thought in terms of contract law. It's a common error. They don't shoot you at dawn for not fully understanding the GPL. But at the same time, it's good to know that the problems people think they see in the GPL generally are the result of not understanding it, not from any weakness in the GPL itself.

Similarly, when you hear that the GPL is viral and can force proprietary code to become GPL, which a couple of lawyers have been saying, you'll know that isn't true. If you steal GPL code, you can expect an enforcement action. But this action can only be enforcement of a license, not a contract, and a forced release under the GPL can't be imposed on you under copyright law. It's not one of the choices, as Professor Moglen has explained. You do have a choice under the GPL: you can stop using the stolen code and write your own, or you can decide you'd rather release under the GPL. But the choice is yours. If you say "I choose neither," the court can impose an injunction to stop you from further distribution, but it won't order your code released under the GPL. Your code remains yours, as you can see, even in a worst case scenario.

Of course, you could avoid all such troubles in the first place by not stealing GPL code to begin with. But if something happens inadvertently and some rogue employee sneaks some GPL code into your proprietary product, the sky isn't falling. It's a manageable risk and a solvable problem. No one wants to steal your code in retaliation or force it to be something you don't want it to be. The GPL is unequivocally a license, and that's the truth.

Comments (91 posted)