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.
Named memory and heap
Shared libraries, shared memory segments
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
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
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
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)
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
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
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.
We were not very sure about exactly what to do, and definitely some fear
[of Linux], that it would cannibalize some of our business. We had an
internal [Linux] project, gave up based on GPL fear and issues. In 2001 we
announced acquisition of BSD assets. We thought that what customers wanted
was attributes of Linux, delivered with BSD. This year, you know, through a
lot of thinking and changes... we realized we were wrong.
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:
The primary market focus is on Linux and not [Unix]. We took a risky bet
that BSD was going to be the business-friendly alternative to Linux, but
that turned out not to be the case. [Unix] became Betamaxed to Linux's
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
When you manage and design software, you have to use best practices to
understand how you don't contaminate your own code with other IP, whether
it's coming from a third-party or open source...but I think we should let
the people involved [determine] if the GPL is really enforceable or an
issue or not.
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)
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
(See also: this IP
Justice press release).
Comments (5 posted)
[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
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
The word 'license' has, and has had for hundreds of years, a
specific technical meaning in the law of property. A license is a
unilateral permission to use someone else's property. The
traditional example given in the first-year law school Property
course is an invitation to come to dinner at my house. If, when
you cross my threshold, I sue you for trespass, you plead my
'license,' that is, my unilateral permission to enter on and use my
A contract, on the other hand, is an exchange of obligations,
either of promises for promises or of promises of future
performance for present performance or payment. The idea that
'licenses' to use patents or copyrights must be contracts is an
artifact of twentieth-century practice, in which licensors offered
an exchange of promises with users: 'We will give you a copy of
our copyrighted work,' in essence, 'if you pay us and promise to
enter into certain obligations concerning the work.' With respect
to software, those obligations by users include promises not to
decompile or reverse-engineer the software, and not to transfer the
Very clear, but what about
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:
The GPL, however, is a true copyright license: a unilateral
permission, in which no obligations are reciprocally required by
the licensor. Copyright holders of computer programs are given, by
the Copyright Act, exclusive right to copy, modify and redistribute
their programs. The GPL, reduced to its essence, says: 'You may
copy, modify and redistribute this software, whether modified or
unmodified, freely. But if you redistribute it, in modified or
unmodified form, your permission extends only to distribution under
the terms of this license. If you violate the terms of this
license, all permission is withdrawn.'
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:
Because the GPL does not require any promises in return from
licensees, it does not need contract enforcement in order to work.
A GPL licensor doesn't say in the event of trouble "But, judge, the
licensee promised me he wouldn't do what he's doing now." The
licensor plaintiff says 'Judge, the defendant is redistributing my
copyrighted work without permission.' The defendant can then
either agree that he has no permission, in which case he loses, or
assert that his permission is the GPL, in which case he must show
that he is obeying its terms. A defendant cannot simultaneously
assert that the GPL is valid permission for his distribution and
also assert that it is not a valid copyright license, which is why
defendants do not 'challenge' the GPL.
The claim that a GPL violation could lead to the forcing open of
proprietary code that has wrongfully included GPL'd components is
simply wrong. There is no provision in the Copyright Act to
require distribution of infringing work on altered terms. What
copyright plaintiffs are entitled to, under the Act, are damages,
injunctions to prevent infringing distribution, and--where
appropriate--attorneys' fees. A defendant found to have wrongfully
included GPL'd code in its own proprietary work can be mulcted in
damages for the distribution that has already occurred, and
prevented from distributing its product further. That's a
sufficient disincentive to make wrongful use of GPL'd program code.
And it is all that the Copyright Act permits.
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 (87 posted)
Page editor: Jonathan Corbet
Next page: Security>>