Keeping administrators up to date

Keeping up with distribution security updates is typically straightforward, but finding out about vulnerable packages before they have been patched can be rather harder. There is generally a lag between the report of a vulnerability and the availability of an updated package. In that window, there might well be steps that administrators could take to mitigate or work around the problem, but they can only do so if they are aware of the problem. In our recent article that looked at distribution response to the MoinMoin and Rails vulnerabilities, there was a suggestion that distributions could do more to help notify administrators of known-but-unpatched security holes. As it turns out, a comment on that article led us to one example of just such an early warning system.

The tool in question is debsecan (Debian security analyzer), which helps Debian administrators keep up with the vulnerabilities reported against the packages they have installed. By consulting the Debian security bug tracker, debsecan gets information about entries in the CVE (Common Vulnerabilities and Exposures) and National Vulnerability Database lists that it can correlate with the packages installed on the system. It runs hourly by default, and can email interested parties with its results once per day.

Debsecan was written by Florian Weimer, starting back at the end of 2005; at this point, it is fairly stable and has remained largely unchanged since mid-2010. The program is less than 1500 lines of Python, with just a few dependencies (e.g., libapt-pkg bindings). That dependency and the reliance on the bug tracker make it quite Debian-specific, of course, but the idea behind it is more widely applicable.

Obviously, debsecan depends on the information in the security bug tracker being kept up to date. That is handled by the Debian security team, though volunteers are welcome. The team has put together an introduction to the security bug tracker that describes the process it uses to track security problems for Debian. Other distributions also track security problems, of course, but tools like debsecan that specifically look for problems that have not yet been patched are not common.

Ubuntu carries debsecan in its repositories, but it is too Debian-specific to be directly useful on Ubuntu and, so far, efforts to Ubuntu-ize it have not gone anywhere. At this point, the package is targeted for removal from Ubuntu, because it "conveys information that is just plain wrong" for Ubuntu. For other distributions, package managers (e.g., yum, zypper) will list available updates, and can often filter that list based on security updates, but don't list unpatched packages.

It is, of course, best if a distribution can keep up with the security problems in its packages, but that can be difficult at times. Like with the recent MoinMoin and Rails vulnerabilities, though, there are often ways to mitigate a particular problem—if the administrator is alerted. Even if there is no workaround available, an administrator could choose to completely disable the affected package (or install a patched version from source) while awaiting a distribution update. There is some similarity with the arguments in favor of "full disclosure" here: essentially, the more each individual knows about the vulnerabilities of their software, the more options for handling the problem they have. Without that information, those options are severely limited—in fact, largely non-existent.

One could imagine a cross-distribution project that gathered the same kind of information as the Debian security bug tracker, but in a more distribution-independent fashion. Each distribution could have a tool that processed that data, correlated it to its package names and versions, and then reported on what it found. It could even potentially be extended to help track software that is installed from source.

Keeping up with security updates for source installations can definitely be a problem area. While many larger projects have advisory announcement mailing lists, there are plenty of smaller projects that aren't quite as formal. That means that there are multiple sources of security advisories that an administrator needs to keep track of. By maintaining some kind of list of locally installed packages, coupled with a central storehouse of vulnerabilities, a tool like debsecan could also be used to provide alerts to security holes in local source-installed packages as well.

There are plenty of reasons that administrators will install from source—new features and bug fixes, compatibility with other packages, and so on. Those packages are often things like fast-moving web frameworks or applications that have high risk profiles. A tool that helped administrators keep up with the security issues in source packages, while also integrating the distribution package vulnerabilities and updates, would be a real boon for Linux.