LWN.net Weekly Edition for March 24, 2005

RHEL, kernel vulnerabilities, and days of risk

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] which 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:

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:

CAN #	Disclosed	Fixed	Days	Description
CVE-2004-0001	2004-1-16	2004-1-16	0	x86-64 ptrace bug
CVE-2004-0077	2004-2-18	2004-2-20	2	mremap() local root exploit
CAN-2004-0109	2004-4-14	2004-4-22	8	ISO9660 buffer overflow
CAN-2004-0424	2004-4-20	2004-4-22	2	ip_setsockopt() local root exploit
CAN-2003-0461	2002-5-2	2004-5-11	737	TTY char count information leak
CAN-2003-0465	2003-7-11	2004-5-11	305	strncpy() potential information leak
CAN-2003-0984	2003-12-4	2004-5-11	159	RTC information leak
CAN-2003-1040	2003-12-4	2004-5-11	159	kmod local denial of service
CAN-2004-0003	2004-1-15	2004-5-11	116	DRI range checking
CAN-2004-0010	2004-2-18	2004-5-11	83	ncpfs buffer overflow
CAN-2004-0427	2004-4-8	2004-6-17	70
CAN-2004-0495	2004-6-17	2004-6-17	0	Potential driver bugs found by sparse
CAN-2004-0554	2004-6-9	2004-6-17	8	Floating point denial of service
CAN-2004-0497	2004-7-2	2004-7-2	0	NFS group permissions
CAN-2004-0178	2004-3-8	2004-8-3	148	SoundBlaster denial of service
CAN-2004-0415	2004-8-3	2004-8-3	0	64-bit information leak
CAN-2004-0447	2004-6-19	2004-8-3	45	ia-64 denial of service
CAN-2004-0535	2004-6-3	2004-8-3	61	e1000 driver information leak
CAN-2004-0587	2004-5-4	2004-8-3	91	qla driver denial of service
CAN-2004-0136	2004-6-14	2004-12-2	171	ELF binary denial of service
CAN-2004-0619	2004-6-23	2004-12-2	162	Broadcom 5820 driver buffer overflow
CAN-2004-0685	2004-8-25	2004-12-2	99	USB driver information leak
CAN-2004-0812	2004-11-8	2004-12-2	24	x86_64 TSS error
CAN-2004-0883	2004-11-17	2004-12-2	15	smbfs remotely exploitable vulnerabilities
CAN-2004-0949	2004-11-17	2004-12-2	15	smbfs packet reassembly
CAN-2004-1068	2004-11-19	2004-12-2	13	Datagram serializing problem
CAN-2004-1070	2004-11-10	2004-12-2	22	ELF loader overflow
CAN-2004-1071	2004-11-10	2004-12-2	22	ELF loader mmap() failure
CAN-2004-1072	2004-11-10	2004-12-2	22	ELF loader interpreter name buffer overflow
CAN-2004-1073	2004-11-10	2004-12-2	22	ELF loader file disclosure
CAN-2004-0565	2004-5-28	2004-12-23	209	ia-64 floating point information leak
CAN-2004-1016	2004-12-14	2004-12-23	9	sendmsg() denial of service
CAN-2004-1017	2004-12-10	2004-12-23	13	Edgeport driver buffer overflow
CAN-2004-1137	2004-12-14	2004-12-23	9	IGMP remote exploit
CAN-2004-1144	2004-12-22	2004-12-23	1	x86_64 32-bit emulation local root exploit
CAN-2004-1234	2004-4-8	2004-12-23	113	ELF denial of service
CAN-2004-1335	2004-12-15	2004-12-23	8	IP options integer overflow

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)

A look at Ubuntu "Hoary Hedgehog" and Kubuntu

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 "multiverse" repositories.

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

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

Comments (15 posted)

GreaseMonkey: a two-edged sword

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 is GreaseMonkey. 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 associate JavaScript programs with specific sites on the net. When one of 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.

The GreaseMonkey 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 written.

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 about it.

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)