On July 7, the folks at rPath sent out a security update
for a pair of
kernel vulnerabilities. The update reads, in part:
Previous versions of the kernel package are vulnerable to two
denial of service attacks. The first allows any local user to fill
up file systems by causing core dumps to write to directories to
which they do not have write access permissions.
The bug in question is designated CVE-2006-2451; it was fixed in the 188.8.131.52 kernel release. All
kernels since 2.6.13 are vulnerable, but one cannot just rely on the
nominal version number: Red Hat helpfully backported this bug into
the 2.6.9 kernel shipped with RHEL4.
Reading the description above, some system administrators may feel that
there is no particular urgency in applying this update. The risk that a
rogue user would fill up a disk with core dump files may seem small, so an
update fixing the problem - and which requires a system reboot to be
effective - can maybe be deferred for a while. After all, the Linux kernel
core dump code takes pains to avoid overwriting files with core dumps, so
the real potential for harm is small. It's a denial of service bug.
Except that it's not. All that is required is to create a program
containing a string in the format understood by cron, send it over
to /etc/cron.d, and use the bug to create a core dump there.
Eventually cron will wander along, helpfully pick the line it
understands out of the surrounding binary junk, and execute (as root) the
commands found there. It is a simple and straightforward local root
exploit; an example implementation has been posted to the full-disclosure
Paul Starzetz has posted a complaint about
the characterization of a fully-exploitable vulnerability as a denial of
service problem; he has seen this done with other vulnerabilities as well.
He is right. "Denial of service" makes the vulnerability seem less severe,
especially if it is only exploitable locally. Those words may cause
vulnerabilities to remain open longer by inspiring inaction on both the
administrator and distributor sides. If a bug can be exploited for
privilege escalation, it should not be described as a denial of service
To its credit, Red Hat (which is where the bug was discovered) notes that
the bug could be exploited to gain root privileges. Ubuntu, which closed the vulnerability four days
later, says "This could be exploited to drain available disk space on
system partitions, or, under some circumstances, to execute arbitrary code
with full root privileges." This advisory could use an edit as
well: "under some circumstances" makes the exploit seem unlikely or
difficult. A more accurate wording would be "if the attacker wants."
Lest it seem that rPath and Ubuntu are receiving too much grief: as of this
writing, five days after disclosure, rPath, Ubuntu, and Red Hat are the
only distributors to have fixed this problem. They have done the
most important part: making an update available. All other
distributors who have shipped kernels based on 2.6.13 or later remain
vulnerable to a trivial local root exploit. Might this slow response be
caused, in part, by the perception that this is a mere local denial of
As a community, we feel that we have the best security support out there.
Vulnerabilities are not hidden, and fixes come promptly. In cases like
this one, however, we have let our users down. Presenting an easily
exploitable root vulnerability as a denial of service problem is just the
sort of obfuscation that we normally try to avoid. And the fact that a
number of distributions remain vulnerable is a failure to live up to our
own promises. We can - and must - do better than that.
Comments (27 posted)
The press release from the Software Freedom Law Center came with an
attention-getting headline: Software
Freedom Law Center Clears OpenDocument Format for Free Software Use
Since a number of free software projects have supported OpenDocument for
some years now, and since OpenDocument has been heavily promoted as a way
of leveling the office suite playing field, many in the community may have
been surprised to see SFLC jumping in to "clear" the format at this time.
Still, free software developers will be glad to know that "...that
they can legally implement OpenDocument Format (ODF) in free and open
source software. OpenDocument Format is a free file format for saving and
exchanging editable documents, spreadsheets, databases and
The problem is that the legal
opinion from SFLC says no such thing. With all legal texts, one is
well advised to read the fine print; in this case, the small text makes it
clear that SFLC's survey was of a rather more limited scope than the press
release would suggest.
The SFLC analysis was seemingly inspired by concern over the patent
policies of OASIS, the standards body which has adopted ODF. OASIS
standards can include patented technology; depending on the policy chosen
when a given standard process starts, those patents need not be made
available under any sort of license compatible with free software. In the
case of ODF, however, the standard was developed in the "royalty free on
limited terms" mode. Whether the standard is truly free, in the end,
depends on whether the "limited terms" are workable or not.
So the SFLC went to look at the patent terms disclosures required of the
standard committee's members. Only Sun had filed such a disclosure, and
Sun's terms were deemed to be reasonable. From this work, SFLC concluded
that none of the OASIS standard committee members have any patents which
they will be able to assert against those who implement OpenDocument. None
of the companies which put together this standard have any submarine
patents lurking below the surface.
This is good to know, but the disclaimer text makes it clear just how
limited this statement is:
Patent-holders not qualifying as Obligated Members of the OASIS
Technical Committee may in future assert essential
claims. Obligated Members could in future assert non-essential
claims... Programs with additional
functionality beyond the implementation of the ODF standard,
including programs with office suite functionality, may in fact
practice licensed essential claims outside the field of use
restriction of one or more licenses... This opinion
expresses no view of the validity of any patent, nor whether any
patent is infringed by ODF or by any implementation thereof. No
patent search has been conducted in connection with the preparation
of this opinion.
So SFLC did not actually go looking for possibly relevant patents. Given
the current state of affairs, the existence of patents which could possibly
applied to ODF seems almost certain. Searching them out would have been
pointless; in this field, it is often simply better not to know about
possible patent problems. So, while the SFLC has done a good thing by
ruling out one particular set of potential ODF patent problems, there are
limits to the extent to which ODF can be "cleared for free software use."
As long as the current patent regime exists, free software will never be
Comments (1 posted)
Your editor, having a distinct masochistic streak, runs several different
computers, each with a different Linux distribution. For added pain, most
of them run the bleeding-edge, development version of their particular
distribution. As a result, surprises
are, well, not particularly surprising. Even so, your editor's x86-64
system running Fedora development (the distribution formerly known as
"Rawhide") managed to raise some eyebrows recently - and the news was not
One of the endearing features of Fedora Development on x86-64 is that the
chances of running "yum update" successfully at any given time tend to be
less than 50% - especially if the system has any packages from Extras
installed. Between dependency hassles and travel, this particular system
had not been updated in some time. Your editor finally broke down, deleted
a few packages which were blocking the update, and set off on what looked
like a plausible attempt to catch up to the leading edge. After a quick
check of the current backups, your editor fired off the "yum
After thinking at length and forcing every other process out to swap in
the way only yum can do, the word came back: the system could be updated,
at the cost of downloading some 420 packages. Installing that many
potentially unstable packages onto an important system requires a
significant girding of loins - a state of preparedness which can be
difficult to maintain while waiting for all those packages to download from
the (not particularly speedy) mirror network. Once that process completed,
yum had another long think, then announced a file conflict:
/usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted
with the same file in openoffice.org-writer-2.0.3-5.
Yum, of course, refused to update the system. That much is understandable,
but its subsequent decision to delete all 420 downloaded (but uninstalled) packages
can only be seen as gratuitous and mean-spirited.
To the uninitiated, it would appear that yum is complaining about a package
conflicting with itself. Experienced Fedora x86-64 users, however,
recognize the problem immediately: the x86-64 and i386 versions of the same
package are refusing to play well together. This was, thus, your editor's
introduction to the good news portion of this exercise: Fedora Development
now has a native 64-bit version of OpenOffice.org. All that was necessary
was to manually clear out the old, 32-bit version and rerun the update (in
the process re-downloading all 420 packages). Some quick tests show that
the 64-bit OpenOffice.org appears to work, and your editor can now begin
the task of cleaning out the vast pile of 32-bit libraries that
OpenOffice.org traditionally dragged onto the system with it.
While a full assessment is yet to be made, it is your editor's opinion that
OpenOffice.org was the last 32-bit application running on this 64-bit
system. That means that the whole multi-architecture support
infrastructure needed to run 32-bit programs can now go away, and it will
not be a moment too soon.
Multiple architecture support seems like a nice idea. With a bit of work,
a system can transparently run binaries compiled for a different
architecture. That can be good for system migrations, and it can make it
easier to grab precompiled (or proprietary) applications from elsewhere and
quickly make use of them. It allowed your editor to run OpenOffice.org
even though that application was not able to build and run properly on your
But multiple-architecture support can be an administrative nightmare.
Keeping multiple versions of the same package synchronized can be a
challenge, and, if the package creators are not careful, they will not mix
well together. It is amazing how many libraries must be dragged along for
both architectures; the inevitable crufting up of the system happens much
more quickly. Your editor never asked to have two versions of MySQL, CUPS,
gphoto, GTK2, PAM, etc., but they showed up anyway.
And one can only hope that whoever came up with
/lib64 has had the opportunity to spend much time in a solitary
cell with a bunch of applications using old configure scripts.
In a world where applications cannot be rebuilt, multiarch support might be
a life saver. But, in a free software environment, we should not need it.
We can build our programs to run on the target's native architecture, and
need not saddle ourselves with the overhead and hassles of multiarch
support. Your editor is looking forward to cleaning up the some 140 i386
packages still on this system - they should not be needed anymore.
Comments (49 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Wireless driver vulnerabilities; New vulnerabilities in gimp, the kernel, libmms, samba, ...
- Kernel: Initramfs and where user space really begins; execns(); Crash-only software.
- Distributions: Book review: Red Hat Fedora 5 Unleashed; BLAG-50000; Univention Corporate Server
- Development: The Elisa Media Center project, KDE's Unity project,
new versions of Samba, FreeImage, SELinux Policy Editor, Sussen,
Campsite, MediaWiki, MoinMoin, Plone, Sfront, Traverso, GnuCash, Wine,
SquirrelMail, AbiWord, phpMyAdmin, EasyEclipse.
- Press: Rethinking Community Documentation, Doc Searls on network neutrality,
coverage of EuroPython, Four Core and PostgreSQL Summit, high school
dumps Linux lab, Tom Carey on the FireStar lawsuit, using BASE and Snort,
hardware diagnostics, Portland Project beta, Dave Phillips blog on audio.
- Announcements: Lotus Notes for Linux, Opera 9 for Ubuntu, Trolltech completes IPO,
free download of VMWare, FSFE on Microsoft fines, LPI in China,
Linux hardware database, EFF's DRM questions, Infosec training, OSI
board at OSCON, LQ Jobs Marketplace.