Leading items

Waiting for Rockbox 3.0 - again

Rockbox is a GPL-licensed replacement firmware for a number of digital audio players. LWN published an article on the imminent Rockbox 3.0 release in May, 2006. Well over two years later, it is clear that some projects use a larger value of "imminent" than others. In this case, the Rockbox developers concluded that certain problems simply were not going to be resolved in any reasonable 3.0 time frame; rather than make a major release with known problems, they simply gave up on 3.0 at that time. As a result, the current stable Rockbox release is Rockbox 2.5, from September, 2005.

It is probably safe to bet that few Rockbox users are running 2.5, which only had support for a handful of Archos players. Grabbing a daily build is a fact of life in the Rockbox community. Meanwhile, Rockbox has performed a valuable service for Debian developers who would otherwise have to struggle to find a project with longer release cycles than their own.

Perhaps that state of affairs is about to change. Back in July, the project announced that, once again, an attempt was to be made for a 3.0 release. On August 15, Rockbox went into feature freeze, with the 3.0 release planned for "within a couple (as in two) weeks." That, of course, was a few (as in three) weeks ago, but this release is clearly getting closer.

Now would seem like the time for the project to begin its hype campaign with lots of screenshot-heavy articles on all of the features this major release will bring. Evidently the Rockbox developers have some strange ideas about actually working on the code, though; they haven't gotten around to the promotional side of things yet. So, while the Rockbox manual is reasonably comprehensive and current, it's hard to come up with a list of changes for the 3.0 release.

At the top of any list would have to be the list of supported players, which has expanded considerably since the 2.5 release. The Rockbox buyer's guide gives a good summary of the currently-supported players. Alas, none of these players are currently in production, though some can still be found on auction sites and elsewhere. There is progress toward support for some more contemporary players; early successes have been announced for the Cowon iAudio D2 and iAudio i7 devices. Those players will not be supported in the 3.0 release, of course, and the Rockbox developers have reserved the right to withhold support for other players as well if it is not stable enough.

Beyond that, changes to Rockbox in recent times include the ever-growing list of codecs (including some video formats on suitable players), a five-band parametric equalizer, an increasingly powerful theme capability with many user-contributed themes, album art display, a highly capable tag database, Speex codec support for the voice-based interface, and a whole host of new plugins including the much-anticipated Lamp plugin which displays a blank screen at full intensity, turning your player into an expensive, short-lived flashlight. Rockbox 3.0, it seems, will have something for almost everybody.

[PULL QUOTE: Given that installation can be a bit of a sweaty-palms experience overshadowed by the fear of turning that nice, new player into a brick, any help which can be given is more than welcome. END QUOTE] It also appears that 3.0 may include the hard-to-find RBUtil program - a Qt-based tool which automates the process of installing Rockbox. Given that installation can be a bit of a sweaty-palms experience overshadowed by the fear of turning that nice, new player into a brick, any help which can be given is more than welcome. Bricks, after all, are not known for high-fidelity sound.

Another recent event in the Rockbox community is the creation of the Rockbox Steering Board, currently consisting of Daniel Stenberg, Linus Nielsen Feltzing, Dave Chapman, Paul Louden, and Jens Arnold. The mandate for this board is not particularly clear; it seems to be intended to help break deadlocks in technical discussions. There have been some concerns raised that the creation of this board is a sign that Rockbox is moving into a more bureaucratic, slow-moving mode, but those worries are probably premature.

Rockbox developers also recently decided that all of the project's code would be licensed as "GPLv2 or later." While there is no plan for Rockbox to switch to GPLv3, the developers wanted their code to be available to other projects which are using that license. Since Rockbox does not require copyright assignments, this change will require an audit to find any GPLv2-only code and either relicense it or remove it. There have been no public announcements on how that process is going.

The Rockbox project faces a number of challenges. Cooperation from vendors is essentially zero, so all ports require a reverse engineering effort. Target platforms go through their market lifecycle quickly, making it difficult to get a port stable before the target device disappears. Its programming environment is highly specialized and resource-constrained, limiting the pool of developers who can work on the project. And, someday, the whole effort may lose its relevance as platforms become more capable and it gets easier to just run Linux on them. For now, though, there is nothing better for those who want a dynamic and user-oriented operating system for their digital audio player, and it continues to improve.

Comments (11 posted)

Fedora distributes new keys

The Fedora project is back on track after its recent "infrastructure issues" with new package signing keys as well as packages and updates signed with the new keys. Fedora users should be able to pick up the new key and update their systems now, with a minimum of hassle—just verifying and accepting the new key. But, no further information has been released about exactly what went wrong, leading to more speculation and some worry in the Fedora community.

When a user gets a package from their distribution—or, more likely, a mirror of their distribution repository—they need to have some way to determine that it is a valid package. Distributors sign packages using a private key; that signature can then be verified by using the distribution's public key. If the private key gets compromised somehow, malicious packages could be created that would be indistinguishable from the real versions. This is why private signing keys must be well guarded, usually by isolating them on separate machines and encrypting them with a password.

According to one of the announcements about the problem, there is no evidence that the passphrase used to guard the Fedora private signing key has been compromised, though the clear implication is that the encrypted key file may have been captured. Out of an abundance of caution—and perhaps the concern that the passphrase might be guessed or brute-forced—the project decided to generate new keys. Along with new keys come various headaches: re-signing all of the packages as well as getting the keys installed on user's machines.

Getting the keys to users is largely a matter of getting the new fedora-release package—along with PackageKit and friends for GUI-enabled updates—installed. That package contains the new key and repository name (updates-newkey). Of necessity, those updates are the last that will be signed with the old key, so they will install on existing Fedora systems. Once that package makes its way out to the mirrors, users can install it so that they can proceed with any needed updates using the new key.

A yum clean metadata was helpful at the time of this writing to accelerate the process; depending on which mirror is being used and when it gets updated, that may not be needed. After fedora-release is installed, yum list updates gives a long list of updates available, all signed with the new key. All a user needs to do is verify the key and add it to the RPM key database. Verifying the key is a manual step as a user must check its fingerprint against that published on the web site. The method described requires importing the key into gpg, then doing gpg --fingerprint fedora@fedoraproject.org to see the key fingerprint; this is clearly something that could be made easier.

As part of phase one of the re-signing, Fedora has re-signed all Fedora 8 and 9 package updates. Phase two is ongoing, re-signing each package that is distributed as part of the original release of Fedora 8 and 9. Fedora 10 already has a new signing key as well. From the perspective of a possible compromise of the signing keys, things are well on their way back to normal. But there is still the nagging issue of how this all came about to begin with.

Several different questions about the intrusion were directed at the Fedora board from community members in their IRC meeting on September 9. Unfortunately, there was no new information forthcoming, nor was there any indication of when that information might be available. According to the board member Tom "spot" Callaway, information will be released "when we're told that we can by the parties running the investigation, not a second before, and not a second later."

Red Hat is clearly holding all information about the intrusion as a closely guarded secret—whether that is at the behest of law enforcement or just lawyers is unclear. While there was no timeline given, the clear sense that one got from the meeting is that it might be weeks or months before clearance will be granted to even confirm that they know how the intrusion occurred. In addition, the Fedora board has not been officially briefed on the incident; some members have knowledge because of their Red Hat responsibilities, but the rest are in the dark. If one needed a reminder that Fedora is not an independent distribution, but instead is subject to the whims of Red Hat, this is a clear demonstration.

The justification for secrecy is that Red Hat is a publicly traded company so intrusions into its systems need to be treated differently. Some board members believe that had there not been an intrusion into the servers that handle packages for Red Hat Enterprise Linux—that is if it had only been Fedora servers that were affected—the incident would have been handled much more transparently. Overall, the board is clearly unhappy about the situation but, perhaps because they are almost all Red Hat employees, don't see that there is much that can be done about it. That too should serve as a reminder.

It should be noted that Debian has had several server compromises over the years (for example, 1 and 2), which is, perhaps, a poor record of server security, but it is an excellent example of transparency. Debian is rather well known for its independence, which is part of what allows it to be so open. Those incidents do serve as examples; perhaps they are not an exact fit for the current Fedora/RHEL intrusion but that remains to be seen.

It may very well be that Red Hat is between a rock and a hard place here. As a friend to free software, Red Hat is unparalleled, but once in a while it shows that it is foremost a corporation with responsibilities to its shareholders. When those responsibilities conflict with the transparency we have come to expect from free software projects—especially with regard to security issues—that transparency must be set aside. One can argue that Red Hat is being overly protective of the details—confirmation that they either know or do not know how the intrusion occurred for example—but that argument really can't be made until all the facts are known. For that we must wait for the process to run its course.

Comments (28 posted)

Kernel security, year to date

Earlier this year, your editor asked a high-profile kernel developer, in a public discussion at a conference, about the seemingly large number of kernel-related security bugs. Was the number of these vulnerabilities of concern, and what was being done about it? The answer that came back was that security issues aren't a huge concern, that most of the reported issues were obscure local exploits requiring the presence of specific hardware. Serious issues, like the vmsplice() vulnerability, are rare.

More recently, as part of the panic associated with getting a talk together for the Linux Plumbers Conference, your editor decided to take a closer look at kernel vulnerabilities. It turns out that there are, in fact, quite a few of them. The vulnerabilities which have been given CVE numbers in 2008 (so far) are:

CVE	Subsystem	Vuln type	Notes
CVE-2008-0001	VFS	privilege	File access mode bypass
CVE-2008-0007	drivers	privilege	Missing fault() boundary checks
CVE-2008-0009	core	info disclosure	vmsplice() #1
CVE-2008-0010	core	info disclosure	vmsplice() #2
CVE-2008-0352	net	remote DOS	IPv6 packet handling crash
CVE-2008-0598	x86	info disclosure	32-bit emulation exposes memory
CVE-2008-0600	net	privilege	The big vmsplice() hole
CVE-2008-0731	AppArmor	privilege	SUSE AppArmor vulnerability
CVE-2008-1294	core	resource	RLIMIT_CPU limit bypass
CVE-2008-1367	x86	privilege?	GCC 4.3.0 and DF
CVE-2008-1375	VFS	privilege	dnotify race
CVE-2008-1514	s380	DOS	ptrace() crash
CVE-2008-1615	x86	DOS	ptrace() crash
CVE-2008-1619	Xen	DOS	Xen crash (Red Hat kernels)
CVE-2008-1669	VFS	privilege	fcntl() race
CVE-2008-1673	net	remote privilege	ASN.1 buffer overflow
CVE-2008-1675	net	privilege	Tehuti driver overflow
CVE-2008-2136	net	remote DOS	IPv6 SIT tunnel memory leak
CVE-2008-2137	sparc	DOS	mmap() panic
CVE-2008-2148	VFS	DOS	utimensat() missed permission check
CVE-2008-2358	net	remote DOS	DCCP integer overflow
CVE-2008-2365	core	DOS	Red Hat utrace race
CVE-2008-2372	net	DOS	mmap() resource use
CVE-2008-2729	x86	info disclosure	x86_64 copy_*_user() error
CVE-2008-2750	net	remote privilege	PPPOL2TP overflow
CVE-2008-2812	TTY drivers	privilege	NULL pointer dereference
CVE-2008-2826	net	DOS	SCTP memory use
CVE-2008-2931	VFS	privilege	unprivileged mount point changes
CVE-2008-2944	core	DOS	Red Hat utrace double free
CVE-2008-3077	x86	privilege	x86_64 ptrace() crash and use-after-free
CVE-2008-3247	x86	privilege	x86_64 LDT setup error
CVE-2008-3272	sound	info disclosure	OSS unverified device number
CVE-2008-3275	VFS	DOS	Dentry cache memory use (needs UBIFS for exploit)
CVE-2008-3276	net	remote DOS	DCCP integer overflow
CVE-2008-3496	UVC drivers	privilege	UVC driver buffer overflow
CVE-2008-3525	net	privilege	Missing checks in sbni WAN driver
CVE-2008-3526	net	remote privilege	SCTP integer overflow
CVE-2008-3534	VFS	DOS	tmpfs crash
CVE-2008-3535	VFS	DOS	readv()/writev() off-by-one
CVE-2008-3686	net	DOS	IPv6 null pointer dereference
CVE-2008-3792	net	remote DOS	SCTP-AUTH crashes

That is 41 CVE numbers (so far) for 2008 - not a small number. Fully 1/3 of these vulnerabilities were in the networking subsystem, which is scary: this is the most likely place to find remotely-exploitable problems in the kernel. It is true that sites not running SCTP or DCCP can forget about many of those, and IPv6 is responsible for a few of the rest, so most of those vulnerabilities were not a concern for most sites.

Many of the remaining vulnerabilities were in the core kernel or in architecture-specific code. The number of vulnerabilities found in drivers - the part of the kernel which has long been sneered at as containing the worst code - is actually quite small. On the other hand, four of the CVE-listed vulnerabilities (the Xen, AppArmor, and utrace problems) were caused by out-of-tree code added by distributors. There is no way to know how many vulnerabilities were fixed without obtaining a CVE number - or without even realizing that a vulnerability existed in the first place.

When a single program is responsible for this many vulnerabilities, it makes sense to ask why. The kernel, of course, is a very large program; more code means more bugs, some of which will have security implications. Beyond that, though, the kernel runs in a special, privileged environment. Flaws which would simply be fixed as just-another-crash in a normal application are denial-of-service vulnerabilities in the kernel - or worse. So a larger number of vulnerabilities in the kernel does not, by itself, imply that the kernel's code is worse than that of other programs; it only reflects the fact that the consequences of kernel bugs tend to be more severe.

The discovery (and repair) of vulnerabilities does not necessarily imply that our current process is creating a lot of vulnerabilities; it could be that we are mostly fixing older problems. If the developers are fixing vulnerabilities more quickly than they are adding more, life should be good in the long run. The vulnerabilities in the list above vary from those which are very old (affecting 2.4 kernels too) to some which are very new (the UVC driver was added in 2.6.26). Some of them are in code which, while being intended for the mainline, has not yet been merged. It is probably impossible to say whether security problems are being fixed more quickly than they are being created, but one thing is clear: all of that code flowing into the mainline is bringing a certain number of security problems with it.

For that reason, it is a little discouraging that there is little work being done in the kernel community with the explicit goal of improving the security of the kernel. Few patches are reviewed with security issues in mind; the vmsplice() vulnerability, as one example, was a clear failure of the review process. There are undoubtedly many people who are doing fuzz testing and such - some of them are even the good guys - but much of the formal testing going on seems aimed more at API conformance than at security verification. There must be more work going on behind the scenes, but it is still hard to avoid a sense of a certain amount of complacency with regard to security issues.

As a community, we take pride in the security of our system. But one vulnerability per week is not the most inspiring security record. It would be good to find a way to do better than that. Better tools must be a part of the solution, but more thorough code review is also needed. There still is no substitute for a pair of eyeballs looking for ways in which new code might be subverted. Asking for more security-oriented review seems ambitious when code review is already one of the biggest bottlenecks in the development process. But the alternative would appear to be to continue to add to our collection of CVE numbers.

Comments (77 posted)

Page editor: Jonathan Corbet
Next page: Security>>