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.
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 email@example.com 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.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.
Page editor: Jonathan Corbet
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds