Leading items

Denial of reality vulnerabilities

On July 7, the folks at rPath sent out a security update for a pair of kernel vulnerabilities. The update reads, in part:

The bug in question is designated CVE-2006-2451; it was fixed in the 2.6.17.4 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 list.

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 problem.

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 service bug?

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)

OpenDocument: cleared for use?

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 presentations."

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:

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 truly safe.

Comments (1 posted)

The end of the multiarch era?

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 all bad.

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 update" command.

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 editor's system.

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)