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
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
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
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
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
to post comments)