Security Innovation has joined the elite group of Microsoft-funded
researchers who somehow manage to reach pro-Microsoft conclusions. This
company's latest output is a report
on the relative security of Linux and Windows web servers [PDF]
states that Windows is more secure, in this role, than Red Hat Enterprise
Linux. The group did its work
by looking at all of the vulnerabilities fixed by each vendor in 2004 (as
designated by CVE numbers), and determining how much time passed between
the initial disclosure of the problem and the resulting fix. Windows
showed fewer vulnerabilities, and significantly fewer "days of risk" when
disclosed problems lacked a patch.
Those who want to poke holes in this study should be able to find ample
opportunity. Microsoft vulnerabilities are less likely to be disclosed
prior to patching, to the point that the median "days of risk" for Windows
was zero. The report cautions against writing off "low risk"
vulnerabilities, but, somehow, Microsoft simply does not have any
"low risk" problems. Either that, or Microsoft doesn't bother to fix them,
resulting in many undisclosed "days of risk." Red Hat will also have
gotten burned by this libpng
vulnerability, which, by mistake, remained unfixed for two years.
That's a lot of days of risk, even though no known exploits of this
vulnerability took place.
Let's focus on one specific claim, however:
There were thirty one [RHEL] vulnerabilities fixed in 2004 that had
more than 90 days of risk, and of these, seven were designated by
ICAT as high severity... Eleven of these vulnerabilities were in
the operating system kernel.
The report does not list the actual vulnerabilities it looked at, so we'll
have to try to reproduce that work ourselves. Here's the kernel
vulnerabilities fixed by Red Hat in 2004:
The attentive reader may have noticed that this is a rather long list of
vulnerabilities. Summed up, it amounts to a total of 2943 days of risk - a
substantial portion of the 12,415 days of risk cited in the report.
One immediate conclusion is that, in many cases, we are talking about "days
of very low risk." The strncpy() information leak was worth
fixing, but few people were likely to be overly worried during the 305 days
it took for Red Hat to issue updates with that fix. The same is true of
the TTY character count leak (737 days of risk). Both ia-64 users could
probably live with the floating point leak on that platform (209 days of
risk). In other words, many of the vulnerabilities which had a big
contribution to the total number of days of risk were of little concern.
On the other hand, Red Hat was slow in fixing some important
problems. The kmod denial of service and ELF vulnerabilities took months
to fix - and they were clearly (locally) exploitable problems. Red Hat is,
at times, leaving its paying customers with known security problems for
longer than it should.
Interestingly, many of these problems were fixed more quickly in other
distributions - including Fedora Core. Red Hat's stability
goals for its Enterprise Linux line could be an issue here. The need for
more stress and regression testing of kernel updates, combined with a clear
wish to minimize the number of disruptive kernel updates (many updates
fixed several vulnerabilities), is causing those updates to be delayed.
Thus, one might draw the ironic conclusion that, if you want the fastest
security updates, you're better off not paying for them.
There are some more predictable conclusions as well. One is that reports
like the one from Security Innovation still do not mean a whole lot. There
are too many variables; it is hard to get a handle on which system is truly
more secure, and it is too easy to tilt the data in one direction or the
other. Of course, one could look at the number and cost of actual
security incidents, but these Microsoft-funded surveys tend not to do
that. The final, predictable conclusion is this: regardless of how Linux
performs relative to other systems, we are not doing nearly well enough.
As long as we are producing such long lists of bugs (for a single system
component), our claims to security will only hold so much water.
Comments (24 posted)
The Ubuntu team is closing in on its second release. The Ubuntu project
announced the preview release
for 5.04, better known as "Hoary Hedgehog," on March 10; the final release
is scheduled for early April.
The first Kubuntu distribution
release was also announced recently, and is also scheduled for early
April. Kubuntu uses Ubuntu as a base, but with the KDE desktop and related
packages rather than GNOME. We decided to take a look at both releases, to
see how far Ubuntu has come since its inception, and to see what users
could expect in the forthcoming release.
For those not familiar with the project, the Ubuntu distribution is based
on Debian, but with a six month release schedule, much like GNOME and OpenBSD. Releases are supported, meaning
critical bug fixes and security updates, for 18 months. Ubuntu has a bit
narrower scope than Debian, however. Ubuntu supports only three
architectures, Intel/x86, AMD64 and PowerPC, and has a more limited set of
packages (the "main" and "restricted" repositories) to provide updates
for. A larger set of packages are available through the "universe" and
The release numbers may seem like version inflation, but actually reflect
the year and month of the release, hence 5.04 for Hoary Hedgehog and 4.10
for Warty Warthog -- the first Ubuntu release, from October 2004.
We installed the Ubuntu preview release on a Pentium 4 laptop with 1 GB of
RAM. The installation was completely painless, requiring minimal user input
and a bit of patience while packages were downloaded from the Ubuntu
archive. Ubuntu had no problem detecting all of the laptop's hardware. No
manual configuration or tweaking was necessary for X.org or anything
else. Mileage may differ on other hardware, of course.
To install Kubuntu, we simply followed the instructions on the Kubuntu
documentation page. After running "
sudo apt-get install
kubuntu-desktop" and choosing between KDM and GDM, we had Kubuntu,
the KDE 3.4.0 desktop and a number of KDE applications, installed.
Whereas Debian installs a fairly minimal system and then allows the user to
choose packages, Ubuntu and Kubuntu start off with a set of default
applications for typical desktop use, allowing less experienced users to
get started right away without having to decide which application they wish
to use for e-mail, spreadsheets, word processing or web browsing. For
example, Ubuntu installs GNOME 2.10, Evolution, OpenOffice.org, Totem,
Firefox, Synaptic, Gaim, the Gimp, and so forth. Kubuntu installs KDE 3.4,
Konqueror, Kontact, Kopete, Kynaptic, Akregator and other apps for KDE that
most users would (probably) want.
Overall, we like the choice of packages that are installed with Ubuntu and
Kubuntu by default. Developers and power-users will have to grab additional
packages, but for typical desktop use, Ubuntu is ready "out of the box."
Users that prefer other applications should be able to find them in
Ubuntu's universe repository. For example, this writer still prefers XMMS
to Rhythmbox. Though Rhythmbox is the default music player installed with
Ubuntu, XMMS is easily added using Synaptic or apt-get.
By default, Ubuntu does not set up a password for the root user. Instead,
the first normal user set up at install time can use "sudo" to perform
tasks, like installing software or configuring a network card, usually done
by root. This was a bit off-putting at first for this writer, but after a
few days of working with Hoary, it's become second-nature. (In the past,
this writer has simply gotten around using sudo on Ubuntu by running "sudo
su" and setting a root password and using root normally from there on.)
Though GNOME and KDE are the defaults for Ubuntu and Kubuntu, respectively,
KDE and GNOME are not the only desktops available to Ubuntu/Kubuntu
users. There are also packages for XFce, Enlightenment, Blackbox, fvwm and
several other window managers in the Ubuntu Universe repository. This
writer prefers the XFce desktop environment, and has been happily using
XFce with Ubuntu for some time.
Even though this is only a preview release, it seems exceptionally
solid. Though the preview releases contain a lot of "cutting edge"
software, we didn't find any major application bugs or problems of any
kind. We've also been grabbing updates on a regular basis since installing
Ubuntu Hoary, and it's obvious the Ubuntu team is keeping busy.
The only glitches we ran into were, more or less, self-induced. We tried
upgrading from the default 2.6.10 kernel that was installed to the 2.6.11
package that's available. For some reason, our system locked up each time
we tried to log into GNOME or KDE after installing the 2.6.11 kernel. After
going back to 2.6.10, everything ran smooth as silk. There are also 2.4.x
series kernels in the Ubuntu Universe repository for users who require the
2.4.x series for some reason, though we didn't test any of those kernels.
The Hoary release can be found at http://releases.ubuntu.com/hoary/.
Live CDs and install CDs are available for Intel/x86, PowerPC and
AMD64. Users who prefer to go the KDE route can download installation media
or live CDs from http://cdimage.ubuntu.com/kubuntu/releases/hoary/preview/.
The next Ubuntu release is scheduled for October, and has been dubbed "Breezy
Users looking for a cutting-edge Linux distribution that "just works"
should try out Ubuntu. The distribution is put together very well, offers
an excellent selection of packages and a very active and helpful user
Comments (15 posted)
The Mozilla Firefox extension mechanism is a powerful feature; it gives
browser users a great deal of flexibility in controlling how things work.
One of the extensions attracting the most attention in the last few months
. It is, in
fact, a classic example of why free software is a great thing, but also an
illustration of how users can be invited to harm themselves.
The core idea behind GreaseMonkey is simple: it allows the user to
the identified pages (as determined by a regular expression) is loaded, the
script gets a chance to rewrite things before the page is displayed.
GreaseMonkey is, in other words, a mechanism which enables readers to
automatically rework web pages into the form they would have liked them to
be in the first place.
script repository shows that there is a demand for this capability.
Scripts have been posted which:
- Remove articles or comments posted by specific users. Perhaps
this would be a quick way to implement the comment filtering features
occasionally requested for LWN.net.
- Rewrite web pages to get rid of intrusive navigation bars,
interstitial ad pages, etc. For those who want more ads, there is a
script which inserts Google ads into the handful of pages on the net
which do not yet have them.
- Redirect SourceForge download links to skip the mirror selection page
and simply get the requested files.
- Delete Michael Jackson stories from certain news sites
("Best. Userscript. Ever.").
- Rewrite Paul Graham's articles for better readability.
- Create cross links between Netflix and IMDB.
And so on; the list appeared to be growing as this article was being
The operators of various web sites will, beyond doubt, get upset if
GreaseMonkey use takes off. To anybody who wishes to have a high degree of
control over the appearance and use of their site, GreaseMonkey will be a
threat. But GreaseMonkey is a clear expression of software freedom: we
will control how things work on our own computers. Our tools are
written to maximize that control, and there is little that can be done
GreaseMonkey does, however, potentially threaten that control in a
different way. A tool which encourages users to download and run scripts
from random parts of the net would appear to be an open door for security
problems. If the browser's sandboxing works properly, a script should not
be able to affect the system outside of the browser. But even the mere
ability to rewrite HTML is asking for some trouble: how long will it be
until some phisher posts a script that, while perhaps doing something
useful, also redirects links within financial sites? It is not entirely
clear how that sort of problem can be addressed - the same capability which
can redirect all New York Times links to the "printable" version can point
a password submission form to a third-party site.
In other words, while GreaseMonkey is a cool and powerful tool, it should
be used with great care. Install a minimum number of scripts, look them
over first, and, preferably, write them yourself. As the GreaseMonkey
community grows, there will certainly be exploit attempts. Firefox is a
relatively secure web browser; it would be a shame to ruin that by inviting
in random malware from the net.
Comments (7 posted)
Page editor: Jonathan Corbet
Next page: Security>>