LWN.net Weekly Edition for May 8, 2008 [LWN.net]

Rietveld: another code review aid

By Jake Edge
May 7, 2008

With the release of Rietveld, another tool for those interested in doing web-based code reviews is now available. We looked at Review Board back in January. It was inspired by an internal Google tool, written by Python creator and Google employee Guido van Rossum, called Mondrian. That tool in turn spawned Rietveld.

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

There are multiple ways to get a set of patches into the Rietveld system to create an "issue"—the term used for a patch set undergoing review—from an upload of a unified diff to using a python script to retrieve the patches from a repository. Currently Rietveld only supports Subversion, but van Rossum would like to see support added for other version control systems over time. Review Board has a bit of a head start in this area, so it supports Mercurial, Git, Bazaar, Perforce, Subversion and CVS.

Once an issue has been created in the system, reviewers can then be invited to comment on the changes. Navigating through the diff is straightforward, with Javascript being used liberally to give an interactive "local application" feel to the interface. Double-clicking on a line brings up a comment box that a reviewer can fill in to attach some comments to that line. All comments are held as "drafts" until the reviewer is satisfied with their review at which point they "publish" the comments for the author and other reviewers to see.

The Rietveld project is free software, released under the Apache 2.0 license, while the application itself runs via the Google App Engine. Anyone can browse the system, but folks who have a Google account can add issues, comments, and conduct reviews using the tool. Because it uses App Engine, people wanting to try it out on their code need not find a server to install and run the application—as would be required with Review Board—they can just upload a set of patches, invite some reviewers, and proceed.

This kind of simplified deployment is one of the benefits that Google App Engine is meant to provide. For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. Those who wish to keep their source code secret may want to install their own instance of Review Board or another tool. It may be possible to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

While Rietveld does not provide much in the way of additional functionality from Review Board—in fact it lags Review Board in some areas—it does provide a very nice introduction to the Google App Engine interface. Developers will undoubtedly be using the code as a template for their own ideas once Google makes more App Engine accounts available. Given the shared history, language, and framework, it isn't impossible to imagine that Review Board and Rietveld might join forces one day. Even if they don't, some cross-pollination is inevitable which will result in both getting better. Hopefully, with more projects using one or both, better code for the community is the result.

Comments (4 posted)

How not to sell embedded Linux

By Jonathan Corbet
May 6, 2008

Every now and then one should have a look at some unabashed fear, uncertainty, and doubt (FUD) material. It's good to know what the other side is saying, the level of unintended humor is often high, and, on occasion, one even learns something. Your editor's suggestion for FUD of the week is this Embedded.com article by Dan O'Dowd. Therein, one will learn about the impending death of embedded Linux as told by the companies which sell embedded Linux.

In particular, Mr. O'Dowd looks at some marketing material from MontaVista and Wind River, and concludes:

This embedded Linux bashing from embedded Linux's strongest proponents should give pause to those who are thinking through their embedded operating system strategy. If embedded Linux champions are saying that embedded Linux is terrible, why would anyone want to risk their products or their company on it?

One can easily pick holes in this article, starting with the assertion that MontaVista and Wind River are "Linux's strongest proponents." One could also recall that we have heard this kind of thing before; in 2004, Mr. O'Dowd (who happens to be the founder and CEO of a proprietary embedded systems software vendor) helpfully warned us that "intelligence agencies and terrorists" would contribute "subversive software" to Linux and lectured on the need for secret source code to achieve true security. One could point out that many of the points put forward by Mr. O'Dowd appear to be pure fantasy. All of these rebuttals would be valid, but they risk missing an important point to be gained from this article - though it's not quite the point Mr. O'Dowd is trying to make.

Mr. O'Dowd obtains his "facts" from two sources: an advertisement by Wind River Systems (which your editor was unable to find online) and, primarily, from a column by MontaVista founder Jim Ready in Military Embedded Systems magazine. Mr. Ready's evident purpose is to frighten embedded systems vendors into buying his company's services; to that end, he lays it on pretty thick:

To keep abreast of the changes occurring on a daily basis, a developer needs to monitor the email traffic of 11 different and unsynchronized open source projects: kernel.org, the core home of the Linux kernel; the gcc and glibc projects (the core tool chain and libraries from FSF at fsf.org); and at least nine other components that would typically comprise a useable Linux development environment.

Kernel.org itself may have up to 5,000 messages a day with 1,000 of these being patches that need to be evaluated and possibly applied to the source base. Simply ignoring the traffic, figuring that the system in use seems to be working well enough, can lead to disastrous consequences later. For example, a recent security patch that took all of 13 lines of code to implement against an embedded Linux system would have taken more than 800k lines of source patches to implement if the previous trail of patches had been ignored. It's a classic case of pay now or really pay later.

Somebody must have had a great deal of fun putting all of those numbers together. The generation of ordinary random numbers can be managed through traditional methods like a toss of the dice, picking numbers out of a hat, or reading corporate earnings estimates. Randomness on this scale, though, can only be achieved through the use of special-purpose software.

Even by kernel.org standards, 5,000 messages per day is fairly intense, though your editor, a subscriber to the linux-kernel, git-commits-head, and mm-commits lists, can attest that the order of magnitude is right at least. But your editor cannot even begin to grasp the thought process which turns a 13-line security patch into 800,000 lines of code. Imagine posting that to linux-kernel. "Pay now or really pay later" indeed.

But the provenance of the numbers is not really the point here. Mr. Ready is perpetrating the fallacy that, to build an embedded system with Linux, one starts with the various components and integrates them all by hand. If a company were to take that path, it might well incur the high costs that Mr. Ready warns about. Creating your own distribution - and maintaining it over a product's life - is, indeed, a difficult and expensive job.

But it is a rare vendor which does that; even Gentoo users outsource much of the integration work to their distributor. Why would any vendor create its own distribution when there are so many out there to base a product on? Customizing a distribution for an embedded application is not a trivial job, but it's not rocket science either. The distributor will keep up with most of those mailing lists, and, somehow, a reasonable distribution also manages to ship security updates which do not involve 800,000 lines of code. There is no reason for embedded systems vendors to wander into the expensive mess that Mr. Ready describes; the creation of a suitable distribution is much easier than that.

Even so, many vendors may decide that, in fact, they would rather not be in the business of customizing distributions. They might, instead, look to a vendor to do that work for them. It makes perfect sense for companies like MontaVista and Wind River (among others) to offer to provide a stable, integrated, and supported platform to embedded systems vendors for a fee. There is honest value in this line of business.

But one does have to wonder why these companies feel the need to scare companies into buying their services. Those services, properly rendered, have a real value which can be sold without resort to outright FUD. Failure to focus on that value gives encouragement to people like Mr. O'Dowd, who would be most pleased if embedded Linux were to go away altogether. This does not seem like a sensible business strategy. Companies which seek to make money from Linux might just want to think twice before poisoning the well they are trying to drink from. That is the real lesson to be learned from this particular piece of writing.

Comments (27 posted)

Blizzard tests the reach of copyright law

By Jake Edge
May 7, 2008

Free software users rarely, if ever, need to be concerned about the license that governs the applications they use. Unlike developers or distributors, users are unlikely to pay attention to whether a program is released under a BSD, GPL, or some other license—not so with proprietary software. If Blizzard Entertainment has its way, it could get a whole lot worse, with proprietary vendors controlling the behavior of its users and enforcing it by way of the Copyright Act.

Blizzard, makers of the online role-playing game World of Warcraft (WoW), has filed a lawsuit against MDY, Inc., makers of a tool that assists players in gaining levels within the game. The Glider program essentially plays the game for a user, creating a more powerful character, with additional riches, while the user is otherwise occupied. Some would claim it is a legitimate way to avoid some of the drudgery of "leveling up" a new character, while others would see it as a means of cheating. In any case it is clearly a violation of the Terms of Use (TOU) of WoW.

But those terms are only accepted by a user when they agree to the End User License Agreement (EULA) that comes with the game. Blizzard would seem to have plenty of ammunition to take action against players that use Glider, but instead of suing its customers for breach of contract—perhaps they have learned something by watching the music industry—they went after the easier target. Had they only sued MDY for "tortious interference with contracts", it probably would have attracted little attention. But Blizzard did something that aroused the interest of the Electronic Frontier Foundation (EFF), Public Knowledge, and others by trying to stretch copyright law to cover MDY's actions.

Certainly Blizzard is no stranger to using copyright law—in particular the much-despised Digital Millennium Copyright Act (DMCA)—in ways that many have found objectionable. The courts, at least in the Blizzard v. BNETD case, have agreed with Blizzard, though, shutting down the development of an alternative server for players of their games. Because of that, any time Blizzard makes a copyright claim, serious scrutiny from various watchdogs can be expected.

Blizzard's claim is that, by running Glider, its users are not only in violation of the contract they agreed to, but they are also committing copyright infringement. As has been seen in various file-sharing lawsuits, whenever copyright is supposedly violated on a computer, any program even tangentially involved in that violation is then accused of "contributory infringement"; this is the second claim that Blizzard makes against MDY in its suit. Under Blizzard's interpretation, users are allowed to copy the program into the RAM of their computer as long as they do not violate the TOU. If they do violate them, their license to copy to RAM—a necessary step to be able to use the program at all—is terminated; they are infringing Blizzard's copyright and liable for damages starting at $750 per illegal RAM copy.

If Blizzard's interpretation is upheld by the courts, many other acts would also serve as copyright infringements: choosing a character name that violates any of the thirteen name restrictions spelled out in the TOU, transmitting or posting "any content or language which, in the sole and absolute discretion of Blizzard, is deemed to be offensive...", or "anything that Blizzard considers contrary to the 'essence' of the Program", for example. Under those conditions, Blizzard could essentially claim copyright infringement any time they wish; racking up another $750+ each time the program is used.

Public Knowledge outlined two good reasons that the copyright infringement claim should be discarded. It is well established that it is not an infringement if making a copy is required to use the copyrighted material, as it is for software. Blizzard's argument that due to the terms of the EULA, those who buy WoW are not "owners" but instead license the software is also weak. The courts have always looked on software purchases as sales, not rentals under some company-controlled license, in much the same way that music and movies are purchased. Copyright owners would love to be able to eliminate the "first sale doctrine" that allows owners to sell used books and other copyrighted content, but the courts have so far been unwilling to go along.

One would hope that the courts would be persuaded not to see this dispute in terms of copyright either, but there is the risk that a tool used for "cheating" might not get the benefit of a well-reasoned view. There have been many occasions where the US courts have made surprising decisions regarding copyright. Undoubtedly there are various copycat suits waiting in the wings should such a decision be reached. In the end, though, neither Blizzard nor any copycats really want to go after the actual "infringers"—also known as customers—they want to go after others who allow users to use (or abuse) their software in ways they do not like. It is a classic proprietary software control strategy, and, thankfully, something that free software users do not have to endure.

There is an interesting comparison to be made with free software licensing, though. Licenses like the GNU GPL also restrict behavior based on copyright law; GPLv3, for example, makes some specific requirements on the patent-licensing agreements that one can make with third parties. Like Blizzard, those who release software under a free license can make a claim of copyright infringement (not breach of contract) if the terms of that license are not adhered to. There is a crucial difference, though: free software licenses do not regulate the use of the software, only its distribution. By claiming that users of the software violate copyright if it does not like their behavior, Blizzard is attempting to extend the reach of copyright law far beyond anything seen in the free software community.

It is certainly understandable that Blizzard would prefer that its users did not employ Glider or other, similar software. They believe it unbalances the game; making it unfair to other players. In the past, they have temporarily or permanently banned players for using bot software, but Glider is evidently more difficult to detect, which led to the current lawsuit.

Blizzard must police its own game, however, and should not expect others to do it for them. It is hard to see that Glider is doing anything particularly wrong here, though Blizzard may prevail on either or both of its claims. If players want to find ways around things they don't like about the game, they will, unless Blizzard finds technological means to prevent it. It would appear that there is a substantial business opportunity in helping players avoid some of the boring, repetitive parts of playing the game—one that Blizzard currently ignores.

Though there is no direct threat to free software from this litigation (unless one is developing free game-playing robots), any potential expansion of copyright is worth watching. The community relies upon copyright law to enforce its licenses, so watching how judges make decisions about such issues is important. While it may be that Blizzard is in the right to go after "cheaters" and a company that helps them, it should not be doing that by trying to expand the reach of its copyrights to this extreme.

Comments (25 posted)

Cryptographic splicing makes for a Wordpress vulnerability

By Jake Edge
May 7, 2008

Authentication bypass vulnerabilities are particularly painful because they allow an attacker to access and potentially modify things that should be off-limits. It is important to ensure that when fixing that kind of bug, one does not introduce a different, but equally potent, hole. A recent Wordpress vulnerability clearly demonstrates the care that needs to be taken.

The problem started in November 2007, when Steven Murdoch reported a problem with Wordpress authentication cookies. Essentially, the cookie that Wordpress used was an MD5 hash calculated using a value stored in the database's user table. Any attacker that could get read access to the database, via a SQL injection or looking inside a database backup for example, could generate a cookie value that would allow them access as that user.

The password itself was not stored in the database as plaintext, but the value used in the cookie was just a simple MD5 of the stored value. So, the value stored was MD5(password) and the cookie value was MD5(MD5(password)). Murdoch released his advisory in advance of a fix, because the vulnerability was being actively exploited. It was entered as bug #5367 into the Wordpress bug tracking system and a long conversation about how to properly fix it ensued.

As part of that discussion, Murdoch suggested that a paper entitled "Dos and Don'ts of Client Authentication on the Web" [PDF] be consulted. The paper covers various issues regarding cookies and the kinds of attacks that can be made against them. Some, but not all, of its recommendations were followed.

The new cookie scheme was released at the end of March as part of the Wordpress 2.5 release. Authentication cookie values were now calculated using the following (with the '.' operator representing concatenation):

    USERNAME . "|" . EXPIRATION . "|" . MD5(USERNAME . EXPIRATION . secret)

This took into account the hazards of a straightforward hash of a stored value and added an expiration to the cookie, but it failed to protect against a cryptographic splicing attack.

When calculating the hash of the concatenation of the username and expiration (along with a secret known by the server), no delimiter was used between the two. This means that the hash for username "foobar" with expiration "20080507" is the same as the hash for username "foo" with expiration "bar20080507". This allows anyone with a username that begins the same as another username, to generate a legitimate cookie for that other user. Using the example above, user "foobar" could create valid cookies for a user "foo" (or any other prefix substring).

Many Wordpress weblogs allow new users to create an account with any name they choose, so long as it is not already taken. By choosing one that starts with the administrator's username, an attacker can generate a cookie for themselves, modify it slightly, and have a valid cookie to access the administrator account. No password cracking is required, nor is any access to the database needed.

Wordpress 2.5.1 has been released to address this problem. Earlier versions could disable the registration feature and delete or suspend any user accounts with suspicious usernames as a workaround. Though if those suspicious accounts exist, it would not be surprising to find that the real administrator no longer knows the proper password for that account.

The paper that Murdoch referenced clearly indicated the danger from cryptographic splicing, but the Wordpress implementers must have missed it. Cookie authentication schemes are a necessary evil for web applications—it would be nearly unusable to have to authenticate on each page—but they are difficult to get right. A careful reading of the paper will help, as will using already vetted libraries or frameworks. It is one of those things that is hard to get right and extremely important to do so.

Comments (24 posted)

b2evolution: cross-site scripting

Package(s):

b2evolution

CVE #(s):

CVE-2007-0175

Created:

May 5, 2008

Updated:

May 7, 2008

Description:

From the CVE entry:

Cross-site scripting (XSS) vulnerability in htsrv/login.php in b2evolution 1.8.6 allows remote attackers to inject arbitrary web script or HTML via scriptable attributes in the redirect_to parameter.

Alerts:

Debian

DSA-1568-1

b2evolution

2008-05-05

Comments (none posted)

emacs: insecure temp files

Package(s):

emacs21, emacs22

CVE #(s):

CVE-2008-1694

Created:

May 6, 2008

Updated:

May 7, 2008

Description:

From the Ubuntu advisory: Steve Grubb discovered that the vcdiff script as included in Emacs created temporary files in an insecure way when used with SCCS. Local users could exploit a race condition to create or overwrite files with the privileges of the user invoking the program.

Alerts:

Ubuntu	USN-607-1	emacs21, emacs22	2008-05-06
Mandriva	MDVSA-2008:096	emacs	2007-05-06

Comments (none posted)

kernel: several vulnerabilities

Package(s):

linux-2.6

CVE #(s):

CVE-2008-1294 CVE-2008-1375

Created:

May 2, 2008

Updated:

April 3, 2009

Description:

From the Debian advisory: David Peer discovered that users could escape administrator imposed cpu time limitations (RLIMIT_CPU) by setting a limit of 0. (CVE-2008-1294) Alexander Viro discovered a race condition in the directory notification subsystem that allows local users to cause a Denial of Service (oops) and possibly result in an escalation of privileges. (CVE-2008-1375)

Alerts:

SuSE	SUSE-SA:2009:017	kernel	2009-04-03
Mandriva	MDVSA-2008:167	kernel	2008-08-12
CentOS	CESA-2008:0612	kernel	2008-08-06
Red Hat	RHSA-2008:0612-01	kernel	2008-08-04
SuSE	SUSE-SA:2008:032	kernel	2008-07-07
SuSE	SUSE-SA:2008:031	kernel	2008-07-02
SuSE	SUSE-SA:2008:030	kernel	2008-06-20
Ubuntu	USN-618-1	linux-source-2.6.15/20/22	2008-06-19
Ubuntu	USN-614-1	linux	2008-06-03
Mandriva	MDVSA-2008:105	kernel	2007-05-21
Mandriva	MDVSA-2008:104	kernel	2008-05-20
Fedora	FEDORA-2008-3949	kernel	2008-05-14
Fedora	FEDORA-2008-3873	kernel	2008-05-14
CentOS	CESA-2008:0237	kernel	2008-05-09
CentOS	CESA-2008:0233	kernel	2008-05-09
CentOS	CESA-2008:0211	kernel	2008-05-07
Red Hat	RHSA-2008:0233-01	kernel	2008-05-07
Red Hat	RHSA-2008:0237-01	kernel	2008-05-07
Red Hat	RHSA-2008:0211-01	kernel	2008-05-07
rPath	rPSA-2008-0157-1	kernel	2008-05-02
Debian	DSA-1565-1	linux-2.6	2008-05-01

Comments (none posted)

kernel: unspecified vulnerability

Package(s):

kernel

CVE #(s):

CVE-2008-1675

Created:

May 5, 2008

Updated:

August 13, 2008

Description:

From the NVD Entry:

The bdx_ioctl_priv function in the tehuti driver (tehuti.c) in Linux kernel 2.6.x before 2.6.25 does not properly check certain information related to register size, which has unspecified impact and local attack vectors, probably related to reading or writing kernel memory.

Alerts:

Mandriva	MDVSA-2008:167	kernel	2008-08-12
Ubuntu	USN-614-1	linux	2008-06-03
Mandriva	MDVSA-2008:109	kernel	2008-06-03
Fedora	FEDORA-2008-3949	kernel	2008-05-14
Fedora	FEDORA-2008-3873	kernel	2008-05-14
rPath	rPSA-2008-0157-1	kernel	2008-05-02

Comments (none posted)

kernel: memory corruption

Package(s):

kernel

CVE #(s):

CVE-2008-1367

Created:

May 7, 2008

Updated:

July 8, 2008

Description:

GCC 4.3.x no longer sets the x86 direction flag in situations where the ABI standard says the flag should already be cleared; as a result, it may be possible for a local attacker to corrupt memory. See this LWN article for details.

Alerts:

SuSE	SUSE-SA:2008:032	kernel	2008-07-07
SuSE	SUSE-SA:2008:031	kernel	2008-07-02
CentOS	CESA-2008:0508	kernel	2008-06-27
Red Hat	RHSA-2008:0508-01	kernel	2008-06-25
SuSE	SUSE-SA:2008:030	kernel	2008-06-20
CentOS	CESA-2008:0233	kernel	2008-05-09
CentOS	CESA-2008:0211	kernel	2008-05-07
Red Hat	RHSA-2008:0233-01	kernel	2008-05-07
Red Hat	RHSA-2008:0211-01	kernel	2008-05-07

Comments (none posted)

kernel: race condition

Package(s):

kernel

CVE #(s):

CVE-2008-1669

Created:

May 7, 2008

Updated:

August 13, 2008

Description:

The kernel's filesystem locking code suffers from a race condition which could possibly allow a local attacker to execute arbitrary code. This vulnerability has been fixed in the 2.6.25.2, 2.6.24.7, and 2.4.36.4 kernel updates.

Alerts:

Mandriva	MDVSA-2008:167	kernel	2008-08-12
SuSE	SUSE-SA:2008:035	kernel	2008-07-21
SuSE	SUSE-SA:2008:038	kernel	2008-07-29
SuSE	SUSE-SA:2008:032	kernel	2008-07-07
SuSE	SUSE-SA:2008:030	kernel	2008-06-20
Ubuntu	USN-618-1	linux-source-2.6.15/20/22	2008-06-19
Ubuntu	USN-614-1	linux	2008-06-03
Mandriva	MDVSA-2008:105	kernel	2007-05-21
Mandriva	MDVSA-2008:104	kernel	2008-05-20
Fedora	FEDORA-2008-4043	kernel	2008-05-17
Fedora	FEDORA-2008-3949	kernel	2008-05-14
Fedora	FEDORA-2008-3873	kernel	2008-05-14
Debian	DSA-1575-1	linux-2.6	2008-05-12
CentOS	CESA-2008:0237	kernel	2008-05-09
CentOS	CESA-2008:0233	kernel	2008-05-09
rPath	rPSA-2008-0162-1	kernel	2008-05-07
CentOS	CESA-2008:0211	kernel	2008-05-07
Red Hat	RHSA-2008:0233-01	kernel	2008-05-07
Red Hat	RHSA-2008:0237-01	kernel	2008-05-07
Red Hat	RHSA-2008:0211-01	kernel	2008-05-07

Comments (none posted)

kernel: denial of service

Package(s):

kernel

CVE #(s):

CVE-2008-1615

Created:

May 7, 2008

Updated:

August 27, 2008

Description:

From the Red Hat advisory: on AMD64 architectures, the possibility of a kernel crash was discovered by testing the Linux kernel process-trace ability. This could allow a local unprivileged user to cause a denial of service (kernel crash).

Alerts:

Red Hat	RHSA-2008:0585-01	kernel	2008-08-26
Mandriva	MDVSA-2008:167	kernel	2008-08-12
Mandriva	MDVSA-2008:174	kernel	2008-08-19
SuSE	SUSE-SA:2008:038	kernel	2008-07-29
SuSE	SUSE-SA:2008:035	kernel	2008-07-21
Ubuntu	USN-625-1	linux	2008-07-15
SuSE	SUSE-SA:2008:032	kernel	2008-07-07
SuSE	SUSE-SA:2008:031	kernel	2008-07-02
SuSE	SUSE-SA:2008:030	kernel	2008-06-20
Debian	DSA-1588-2	linux-2.6	2008-05-30
Debian	DSA-1588-1	linux-2.6	2008-05-27
CentOS	CESA-2008:0275	kernel	2008-05-21
Red Hat	RHSA-2008:0275-01	kernel	2008-05-20
Fedora	FEDORA-2008-4043	kernel	2008-05-17
CentOS	CESA-2008:0237	kernel	2008-05-09
Red Hat	RHSA-2008:0237-01	kernel	2008-05-07

Comments (none posted)

kernel: Xen-based denial of service

Package(s):

kernel

CVE #(s):

CVE-2008-1619

Created:

May 7, 2008

Updated:

May 9, 2008

Description:

Certain kinds of stress tests on ia-64-based systems running Xen can cause the hypervisor to panic.

Alerts:

CentOS	CESA-2008:0233	kernel	2008-05-09
Red Hat	RHSA-2008:0233-01	kernel	2008-05-07

Comments (none posted)

wordpress: multiple vulnerabilities

Package(s):

wordpress

CVE #(s):

CVE-2007-3639 CVE-2007-4153 CVE-2007-4154 CVE-2007-0540

Created:

May 1, 2008

Updated:

May 7, 2008

Description:

The wordpress weblog manager has a number of vulnerabilities. From the Debian alert:

CVE-2007-3639 Insufficient input sanitising allowed for remote attackers to redirect visitors to external websites.

CVE-2007-4153 Multiple cross-site scripting vulnerabilities allowed remote authenticated administrators to inject arbitrary web script or HTML.

CVE-2007-4154 SQL injection vulnerability allowed allowed remote authenticated administrators to execute arbitrary SQL commands.

CVE-2007-0540 WordPress allows remote attackers to cause a denial of service (bandwidth or thread consumption) via pingback service calls with a source URI that corresponds to a file with a binary content type, which is downloaded even though it cannot contain usable pingback data.

[no CVE name yet] Insufficient input sanitising caused an attacker with a normal user account to access the administrative interface.

Alerts:

Debian

DSA-1564-1

wordpress

2008-05-01

Comments (none posted)

Kernel release status

The current 2.6 prepatch is 2.6.26-rc1, released on May 3. "So this merge window was somewhat rocky in the sense that there was a lot of arguments about it, but at the same time I at least personally think that from a technical angle, we had somewhat less scary stuff going on than has been almost the rule lately." At about 7500 commits, this cycle has fewer changes than the last couple have; a lot of the changes are infrastructural, so there will be fewer obvious new features with 2.6.26 than with some of its predecessors. See the short-form changelog for details, or the full changelog for lots of details.

A relatively slow stream of patches has been heading into the mainline git repository since the -rc1 release.

The current stable 2.6 release is 2.6.25.2, released on May 6. This release contains a single fix for a locally-exploitable security problem in the filesystem locks code. 2.6.24.7 and 2.4.36.4 were also released with this fix.

Previously, 2.6.25.1 and 2.6.24.6 had been released with a larger set of fixes. In the absence of another security issue, there will probably not be any more 2.6.24 stable updates.

Comments (none posted)

Quotes of the week

Usually my git problems are root-caused down to my lack of a PhD in hermeneutic metaphysiology, but not this time, methinks.

-- Andrew Morton

Kids: do not shove random modules into your kernel. Just because Linus does something doesn't make it a good idea...

We've moved half the kernel brains to userspace with udev, initrd and modules; it's really unfair that you're not sharing all that why-won't-my-machine-boot love.

-- Rusty Russell

[T]he kernel team has evolved from a small team of buddies to a large enterprise. And to survive this evolution, we may need to apply the immoral principles found in big companies.

-- Willy Tarreau

Comments (7 posted)

The last things through the 2.6.26 merge window

By Jonathan Corbet
May 5, 2008

About 500 changesets were merged after the publication of the first and second 2.6.26 merge window summaries. The merge window is now closed; here is the final set of changes which got in:

New drivers for Solarflare Communications Solarstorm SFC4000 controller-based Ethernet controllers, Hauppauge HVR-1600 TV tuner cards, ISP 1760 USB host controllers, Cypress c67x00 OTG controllers, and Intel PXA 27x USB controllers.
8Kb stacks are, once again, the default for the x86 architecture. "Out-of-memory situations are less problematic than silent and hard to debug stack corruption."
The klist type now has the usual-form macros for declaration and initialization: DEFINE_KLIST() and KLIST_INIT(). Two new functions (klist_add_after() and klist_add_before()) can be used to add entries to a klist in a specific position.
As had been planned, struct class_device has been removed from the driver core, along with all of the associated infrastructure. Classes are now implemented with an ordinary struct device.
kmap_atomic_to_page() is no longer exported to modules.
There are some new generic functions for performing 64-bit integer division in the kernel:
```
    u64 div_u64(u64 dividend, u32 divisor);
    u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder);
    s64 div_s64(s64 dividend, s32 divisor)
    s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
```
Unlike do_div(), these functions are explicit about whether signed or unsigned math is being done. The x86-specific div_long_long_rem() has been removed in favor of these new functions.
There is a new string function:
```
     bool sysfs_streq(const char *s1, const char *s2);
```
It compares the two strings while ignoring an optional trailing newline.

The prototype for i2c probe() methods has changed:

     int (*probe)(struct i2c_client *client, 
                  const struct i2c_device_id *id);

The new id argument supports i2c device name aliasing.

There is a new configuration (MODULE_FORCE_LOAD) which controls whether the loading of modules can be forced if the kernel thinks something is not right; it defaults to "no."

Comments (10 posted)

Time to slow down?

By Jonathan Corbet
May 7, 2008

All communities develop rituals over time. One of the enduring linux-kernel rituals is the regular heated discussion on development processes and kernel quality. To an outside observer, these events can give the impression that the whole enterprise is about to come crashing down. But the reality is a lot like the New Year celebrations your editor was privileged enough to see in Beijing: vast amounts of smoke and noise, but everybody gets back to work as usual the next day.

Beyond that, though, discussions of this nature have real value. Any group which is concerned about issues like quality must, on occasion, take a step back and evaluate the situation. Even if there are no immediate outcomes, the ideas raised often reverberate over the following months, sometimes leading to real improvements.

The immediate inspiration for this round of discussion was broken systems resulting from the 2.6.26 merge window. This development cycle has had a rougher start than some, with more than the usual number of patches causing boot failures and other sorts of inconvenient behavior. That led to some back-and-forth between developers on how patches should be handled. Broken patches are unfortunate, but one thing is worth noting here: these problems were caught and fixed even before the 2.6.26-rc1 kernel release was made. The problems which set off this round of discussion are not bugs which will affect Linux users.

But, beyond any doubt, there will be other bugs which are slower to surface and slower to be fixed. The number of these bugs has led to a number of calls to slow down the development process in one way or another. To that end, it is worth noting that the process has slowed down somewhat, with the 2.6.26 merge window bringing in far fewer changesets than were seen for 2.6.24 or 2.6.25. Whether this slower pace will continue into future development cycles, or whether it's simply a lull after two exceptionally busy cycles remains to be seen.

But, if the process does not slow down on its own, there are developers who would like to find a way to force it to happen. Some have argued for simply throttling the process by, for example, limiting new features in each development cycle to specific subsystems of the kernel. There has also been talk of picking the subsystems with the worst regression counts and excluding new features from those subsystems until things improve. The fact of the matter, though, is that throttling is unlikely to help the situation.

Slowing down merging does not keep developers from developing, it just keeps their code out of the tree. An extreme example can be found in the 2.4 kernel: the merging of new code was heavily throttled for a long time. What happened was that the distributors started merging new developments themselves because their users were demanding them. So a lot of kernels which went under the name "2.4" were far removed from anything which could be downloaded from kernel.org. That way lies fragmentation - and almost certainly lower quality as well.

Linus actually takes this argument further by arguing that quickly merging patches leads to better quality:

[M]y personal belief is that the best way to raise quality of code is to distribute it. Yes, as patches for discussion, but even more so as a part of a cohesive whole - as _merged_ patches!

The thing is, the quality of individual patches isn't what matters! What matters is the quality of the end result. And people are going to be a lot more involved in looking at, testing, and working with code that is merged, rather than code that isn't.

Andrew Morton has also argued against throttling:

If we simply throttled things, people would spend more time watching the shopping channel while merging smaller amounts of the same old crap.

Kernel developers are, of course, known to be hard-core shoppers, so giving them more opportunity to pursue that activity is probably not the best idea. Seriously, though: Andrew is in favor of a slower development process, but only when approached from a different angle: his point is that an increased focus on quality will, as a side effect, result in slower development. Kernel developers need to be focused on finding and fixing bugs rather than creating new ones and/or shopping.

It is worth noting that a substantial portion of the development community appears to believe that there are no real problems in this regard. Bugs are being found and fixed at a high rate and the kernel is solid for most users. Arjan van de Ven notes:

Are we doing worse on quality? My (subjective) opinion is that we are doing better than last year. We are focused more on quality. We are fixing the bugs that people hit most. We are fixing most of the regressions (yes, not all). Subsystems are seeing flat or lower bugcounts/bugrates.

Ted Ts'o points out that a lot of problems result from obscure and low-quality hardware, and that it's not possible to make everybody happy. Andrew is unconvinced, though, and seems to fear that the kernel is declining in quality.

In a sense, though, that part of the discussion is moot. Nobody would argue against the idea that fewer bugs is a worthy goal, regardless of whether one believes that the current process has quality problems. So talk of ways to make things better is always on-topic.

Testing remains a big issue; the kernel, more than almost any other project, is highly sensitive to the systems on which it is run. Many problems (arguably the majority of them) are related to specific hardware, or specific combinations of hardware; there is no way for the developers, who do not have all possible hardware to test on, to ever find all of these bugs. Users have to help with that process. Getting widespread testing coverage is always hard; Peter Anvin argues that the current process has actually made that harder:

One thing is that we keep fragmenting the tester base by adding new confidence levels: we now have -mm, -next, mainline -git, mainline -rc, mainline release, stable, distro testing, and distro release (and some distros even have aggressive versus conservative tracks.) Furthermore, thanks to craniorectal immersion on the part of graphics vendors, a lot of users have to run proprietary drivers on their "main work" systems, which means they can't even test newer releases even if they would dare.

There is, in fact, a wealth of development kernels to test, and it is not always clear where users and developers should be concentrating their testing effort. A consensus may be forming, though, that more people should be looking at the linux-next tree in particular. Linux-next is where all of the patches intended for the next merge window are supposed to congregate; the current contents of linux-next, as of this writing, are targeted toward 2.6.27. This is the place where early integration issues and other problems should be found; if linux-next is well tested, the number of problems showing up in the next merge window should be somewhat reduced.

The linux-next tree is an interesting experiment. It is, for all practical purposes, making the development cycle longer: since linux-next exists, the 2.6.27 cycle has, in some sense, already started. Linux-next also does something which kernel developers have tended to resist: causing the stabilization period for one development cycle to overlap with active development for the next cycle. In the past, it has been argued that this kind of overlap will cause developers to prioritize the creation of new toys over fixing the problems with last week's toys.

Some people argue that this is happening now: developers are not spending enough time dealing with bugs - and that their carelessness is creating too many bugs in the first place. Others assert that, while it will never be possible to fix every reported bug, the bugs that really matter are being addressed. A real resolution to this disagreement seems unlikely; the creation of meaningful metrics on kernel quality is a difficult task. About the best that can be done is to try to keep the regression list as small as possible; as long as systems which once worked continue to work, it is hard to argue too forcefully that things are headed in the wrong direction.

Comments (12 posted)

Read-only bind mounts

By Jonathan Corbet
May 6, 2008

Bind mounts can be thought of as a sort of symbolic link at the filesystem level. Using mount --bind, it is possible to create a second mount point for an existing filesystem, making that filesystem visible at a different spot in the namespace. Bind mounts are thus useful for creating specific views of the filesystem namespace; one can, for example, create a bind mount which makes a piece of a filesystem visible within an environment which is otherwise closed off with chroot().

There is one constraint to be found with bind mounts as implemented in kernels through 2.6.25, though: they have the same mount options as the primary mount. So a command like:

    mount --bind -o ro /vital_data /untrusted_container/vital_data

will fail to make /vital_data read-only under /untrusted_container if it was mounted writable initially. On your editor's 2.6.25 system, the failure is silent - the bind mount will be made writable despite the read-only request and no error message will be generated (the mount man page does document that options cannot be changed).

There is clear value in the ability to make bind mounts read-only, though. Containers are one example: an administrator may wish to create a container in which processes may be running as root. It may be useful for that container to have access to filesystems on the host, but the container should not necessarily have write access to those filesystems. As of 2.6.26, this sort of configuration will be possible, thanks to the merging of the read-only bind mounts patches by Dave Hansen.

As it happens, it's still not possible to create a read-only bind mount with the command shown above; the read-only attribute can only be added with a remount operation afterward. So the necessary sequence is something like:

    mount --bind /vital_data /untrusted_container/vital_data
    mount -o remount,ro /untrusted_container/vital_data

This example raises an interesting question: what if some process opens a file for write access between the two mount operations? A system administrator has the right to expect that a read-only mount will, in fact, only be used for read operations. The 2.6.26 patch is designed to live up to that expectation, though the amount of work required turned out to be more than the developers might have expected.

Filesystems normally track which files are opened for write access, so an attempt to remount a filesystem read-only can be passed to the low-level filesystem code for approval. But the low-level filesystem knows nothing about bind mounts, which are implemented entirely within the virtual filesystem (VFS) layer. So making read-only access for bind mounts work requires that the VFS keep track of all files which have been opened for write access. Or, more precisely, the VFS really only needs to keep track of how many files are open for write access.

The technique chosen was to create something which looks like a write lock for filesystems. Whenever the VFS is about to do something which involves writing, it must first call:

    int mnt_want_write(struct vfsmount *mnt);

The return value is zero if write access is possible, or a negative error code otherwise. This call can be found in obvious places - such as in the implementation of open() - when write access is requested. But write access comes into play many other situations as well; for example, renaming a file requires write access for the duration of the operation. So mnt_want_write() calls have been sprinkled throughout the VFS code.

When write access is no longer needed, the "write lock" should be released with a call to:

    void mnt_drop_write(struct vfsmount *mnt);

One of the discoveries which has been made is that write access is needed in rather more places than one might have thought. In particular, it turns out that there is need for mnt_want_write() calls within the low-level filesystems as well as in the VFS layer. So getting the read-only bind mounts patch into shape has been an ongoing process of finding the spots which have been missed and adding mnt_want_write() calls there. In an attempt to make this process a bit less error-prone, Miklos Szeredi has put together a set of VFS helper functions which encapsulate the situations where write access is needed. Those functions have not been merged for 2.6.26, however.

Superficially, mnt_want_write() is easy to understand - it simply increments a counter of outstanding write accesses. The problem with a simple implementation, though, is that a shared, per-filesystem counter would create scalability problems. On multiprocessor systems, the cache line containing the counter would bounce around the system, slowing things considerably.

A common response to this type of problem is to turn the counter into a per-CPU variable, allowing operations on the counter to remain local to each processor. When somebody needs to know the total value of the counters, it's a simple matter of adding each CPU's version; this operation is slow, but it is also rare. On big systems, though, the number of CPUs can be large - as can the number of filesystems, and bind mounts will only increase that number. The result is a multiplicative effect which, once again, is a scalability problem, only this time it manifests itself in the form of excessive memory use.

The read-only bind mounts patch resolves this situation by, in effect, going back to global counters which are cached on specific processors. To that end, each CPU has one of these structures:

    struct mnt_writer {
	spinlock_t lock;
	unsigned long count;
	struct vfsmount *mnt;
    }

At any given time, this structure will hold a local count for one filesystem, represented by mnt. If the processor needs to adjust the write count for that filesystem, it's a simple matter of incrementing or decrementing count. When the processor's attention turns to a different filesystem, it must first adjust the global count for the old filesystem, then it can switch its local mnt_writer structure to the new one. The result is a compromise between purely local and purely global counters which yields "good enough" performance on benchmarks designed to stress the system.

Read-only bind mounts join with other features (such as shared subtrees) to create a flexible set of tools for the construction of the filesystem namespace. It is not clear how much of this functionality is being used at this time, but, as the implementation of containers in the mainline gets closer to completion, there is likely to be more interest in this capability. Linux systems in coming years may have much more complex filesystem layouts than have been seen in the past.

Comments (9 posted)

Linus Torvalds Linux 2.6.26-rc1 ?

Greg Kroah-Hartman Linux 2.6.25.1 ?

Greg Kroah-Hartman Linux 2.6.25.2 ?

Greg Kroah-Hartman Linux 2.6.24.6 ?

Greg Kroah-Hartman Linux 2.6.24.7 ?

v2.6.22.22-op1 ?

Willy Tarreau Linux 2.4.36.4 ?

Andi Kleen i386: Execute stack overflow warning on interrupt stack ?

Ulrich Drepper unify sys_pipe implementation ?

Peter Zijlstra sched_clock_cpu() ?

Subrata Modak [LTP] [ANNOUNCE] The Linux Test Project has been Released for APRIL 2008 ?

Greg KH driver core patches against 2.6.25-git ?

Michael Buesch Add API for weak DMA masks ?

Ramachandra K [PATCH 00/13] QLogic Virtual NIC (VNIC) Driver ?

Alek Du libata: Add Intel SCH PATA Support ?

Bjorn Helgaas PNP: convert resource table to dynamic list, v1 ?

Darrick J. Wong [resend] [PATCH v2] ibmaem: New driver for power/energy meters in IBM System X hardware ?

Michael Kerrisk core_pattern pipe documentation - draft 2 ?

Jorn Engel LogFS merge ?

Artem Bityutskiy UBIFS - new flash file system ?

Al Viro more vfs patches ?

Miklos Szeredi vfs: add helpers to check r/o bind mounts v3 ?

Miklos Szeredi unprivileged mounts git tree ?

Rusty Russell Removal of FUTEX_FD Jan 25

Arjan van de Ven Rename WARN() to WARNING() to clear the namespace ?

Andrea Arcangeli mmu notifier-core v14->v15 diff for review ?

Andrea Arcangeli mmu notifier #v15 ?

Johannes Weiner Rootmem: boot-time memory allocator ?

KOSAKI Motohiro mm: page reclaim throttle v6 ?

Johannes Berg allow netdevices to specify needed head/tailroom ?

Toshiharu Harada TOMOYO Linux ?

Balbir Singh Add rlimit controller to cgroups (v3) ?

Balaji Rao Simple stats for cpu resource controller v3 ?

Natalie Protasevich Kernel Bugzilla: Bug stats ?

Looking ahead to Mandriva Linux 2009

By Rebecca Sobol
May 7, 2008

With Mandriva Linux 2008 Spring out the door, the first steps toward Mandriva Linux 2009 are in progress. Ideas are being collected on this wiki page and Bugzilla is open for suggestions and ideas. The wiki page begins with instructions for entering ideas and suggestions into Bugzilla.

A number of items are in the wish list for kernel and hardware support. The ML 2009 kernel will use libata, the one item already marked as complete (better late than never). Other wishes include an installed and enabled kerneloops package, full support for Lenovo Thinkpads T60/T61 (and T62 in the future) (with all the bells, whistles, drivers, hotkeys, LEDs, etc. working), making Xen work properly (or dropping it), and patches for kernel-level mode setting.

There is a request for virtualbox 1.6 to be added to the toolchain, along with cmake and svn. The RPM, URPMI requests include better separation of free and non-free so that non-free sources do not get installed on an otherwise free system; and better dependency handling.

Some requests involve making it easier to use a lightweight desktop/window manager. There is an Xfce edition for ML 2008.1, but some would like the Xfce edition to be an official part of the 2009 release. Requests for improved icewm support are joined by requests for LXDE, and Enlightenment 17.

No matter how good an installer is, there is always room for improvement and some ideas are on the list. The same could be said for system tools, and several improvements to Drakxtools are also on the list. The list ends with suggestions for better internationalization and localization support.

Those who have ideas about improving Mandriva Linux, now is the time to get involved. File bug reports where features seem to be missing, and help make ML 2009 better than ever.

Comments (none posted)

easys GNU/Linux 4.1

The easys development team has announced the release of easys GNU/Linux 4.1, a Slackware based distribution. "For the first time the new installation and the administration framework for Linux - ALICE (Advanced Linux Installation and Configuration Environment) - is introduced to the public. Both tools have been created in close co-operation with the DARKSTAR Linux and the easys developer team. Due to ALICE now novices and advanced users are able to perform an easy graphical installation of a Slackware Linux system, only a few steps are to be taken."

Comments (none posted)

F9 beta for ia64 now available

A beta release of Fedora 9 for ia64 is available. "F9 is the first Fedora release to be officially supported on ia64. This ia64 build of fedora is the first to be released under the "secondary architectures" project. We have made efforts to make sure that the ia64 release is equal to the release of Fedora for x86, x86_64, ppc and ppc64, however there are some differences that should be noted."

Full Story (comments: 2)

Fedora Unity releases Fedora 8 Updated Re-Spin

The Fedora Unity Project has announced the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 8. "These Re-Spin ISOs are based on the officially released Fedora 8 installation media and include all updates released as of May 1st, 2008. The ISO images are available for i386, x86_64 and PPC architectures via Jigdo and Torrent."

Date(s)	Event	Location
May 15	NLUUG spring conference 2008	Ede, the Netherlands
May 15 May 16	YAPC::Asia 2008	Tokyo, Japan
May 15 May 16	V WHYFLOSS CONFERENCE CORRIENTES 08	Corrientes, Argentina
May 16 May 17	FOSSCamp 2008	Prague, Czech Republic
May 17 May 18	4th Int. Workshop on Software Engineering for Secure Systems (SESS'08)	Leipzig, Germany
May 17 May 18	French-speaking Python Days	Paris, France
May 19 May 23	AFS and Kerberos Best Practices Workshop 2008	Newark, NJ, USA
May 20 May 23	PGCon 2008	Ottawa, Ontario, Canada
May 20 May 21	Digital Standards Organization (Digistan) Workshop	The Hague, The Netherlands
May 21 May 22	EUSecWest 2008	London, England
May 21 May 22	linuxdays.ch Genève	Genève, Switzerland
May 28 May 31	LinuxTag 2008 where .com meets .org	Berlin, Germany
May 29 June 1	RailsConf 2008	Portland, OR, USA
May 29 May 30	SyScan08 Hong Kong	Hong Kong, China
May 30 May 31	eLiberatica 2008 - The benefits of Open and Free Technologies	Bucharest, Romania
June 2 June 5	VON.x Europe	Amsterdam, the Netherlands
June 3 June 4	Nordic Nagios Meet	Stockholm, Sweden
June 6 June 7	Portuguese Perl Workshop	Braga, Portugal
June 6 June 7	European Tcl/Tk User Meeting 2008	Strasbourg, France
June 9 June 13	Python Bootcamp with David Beazley	Atlanta, Georgia, USA
June 10 June 15	REcon 2008	Montreal, Quebec, Canada
June 11 June 13	kvm developer's forum 2008	Napa, CA, USA
June 16 June 18	YAPC::NA 2008	Chicago, IL, USA
June 17 June 22	Liverpool Open Source City	Liverpool, England
June 18 June 20	Red Hat Summit 2008	Boston, MA, USA
June 18 June 20	National Computer and Information Security Conference ACIS 2008	Bogota, Columbia
June 19 June 21	Fedora Users and Developers Conference	Boston, MA, USA
June 22 June 27	2008 USENIX Annual Technical Conference	Boston, MA, USA
June 23 June 24	O'Reilly Velocity Conference	San Francisco, CA, USA
June 28 June 29	Rockbox Euro Devcon 2008	Berlin, Germany
July 1 July 5	Libre Software Meeting 2008	Mont-de-Marsan, France
July 3 July 4	SyScan08 Singapore	Novotel Clarke Quay, Singapore
July 3	Penguin in a Box 2008: Embedded Linux Seminar	Herzelia, Israel
July 5	Open Tech 2008	London, England
July 7 July 12	EuroPython 2008	Vilnius, Lithuania
July 7 July 12	GUADEC 2008	Istanbul, Turkey

LWN.net Weekly Edition for May 8, 2008

Security

New vulnerabilities

b2evolution: cross-site scripting

emacs: insecure temp files

kernel: several vulnerabilities

kernel: unspecified vulnerability

kernel: memory corruption

kernel: race condition

kernel: denial of service

kernel: Xen-based denial of service

wordpress: multiple vulnerabilities

Kernel development

Brief items

Kernel development news

Patches and updates

Kernel trees

Architecture-specific

Core kernel code

Development tools

Device drivers

Documentation

Filesystems and block I/O

Janitorial

Memory management

Networking

Security-related

Virtualization and containers

Benchmarks and bugs

Distributions

News and Editorials

New Releases

Distribution News

Debian GNU/Linux

Fedora

SUSE Linux and openSUSE

Ubuntu family

Distribution Newsletters

Distribution meetings

Distribution reviews

Development

System Applications

Database Software

Mail Software

Security

Web Site Development

Miscellaneous

Desktop Applications

Desktop Environments

GUI Packages

Interoperability

Medical Applications

Music Applications

Office Suites

Languages and Tools

C

Caml

Perl

PHP

Python

Tcl/Tk

IDEs

Version Control

Miscellaneous

Linux in the news

Recommended Reading

Trade Shows and Conferences

The SCO Problem

Companies

Interviews

Resources

Reviews

Announcements

Non-Commercial announcements