Keeping administrators up to date

By Jake Edge
January 16, 2013

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.

to post comments

Keeping administrators up to date

Posted Jan 17, 2013 4:42 UTC (Thu) by joey (guest, #328) [Link] (3 responses)

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

Of course that already exists in a way, in the CVE vulnerability database.

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

This remains the hard part. Starting with the package name, which is fairly free-form in CVE. And then the version, which is more so, especially when distributions may carry patches to the upstream version that affect security. There's something called CPE that might eventually allow automatic package name mapping, but does not seem to be broadly used in CVE entries yet.

It seems unlikely that an automated tool could be accurate enough to work without people doing work behind the scenes. Which is how Debian's security tracker works.

The funny thing about Debian's tracker is that it started out as a nearly free-form text file, in which I took the current list of all CVEs, and started making notes. Soon I had numerous helpers also updating the file, and the ad-hoc formats used for the notes became conventions, which then became formalized and parsed. It's still just a big (145k lines) text file.

The key features that have kept it going this long seem to be that it works well with version control and so the work is easily parallelized amoung contributors; it allows quickly checking through CVE entries to find ones that are relevant; it ensures that everything gets looked at without much chance of a vulnerability falling thru the cracks.

Still, it's salt mines work. I'm continually amazed it's been updated for 9 years solid.

Keeping administrators up to date

Posted Jan 17, 2013 17:58 UTC (Thu) by malor (guest, #2973) [Link] (1 responses)

Thank you, sir, for doing it. You're making my life better, and I appreciate it.

Keeping administrators up to date

Posted Jan 18, 2013 15:04 UTC (Fri) by ortalo (guest, #4654) [Link]

I second the previous comment.

Keeping administrators up to date

Posted Jan 28, 2013 13:01 UTC (Mon) by robbe (guest, #16131) [Link]

> Of course that already exists in a way, in the CVE vulnerability database.
CVE could be it.

My beef is that from the 20 CVEs linked to on the Jan 17 security page, six are still "reserved", i.e. contain no information. That's 30 percent duds, ten days after the LWN issue was released. Are they understaffed?

Thanks to the people at Debian doing the security tracking work.

Keeping administrators up to date

Posted Jan 17, 2013 5:40 UTC (Thu) by gilbert (guest, #81446) [Link]

Another aspect worth mentioning is that debsecan's information can be used to decide to remove packakes based on knowledge of their unpatched vulnerabilities. In other words, if one were sufficiently motivated, he or she could strip out all of the vulnerable packages reported by debsecan; although certain low-level libraries have to many reverse dependencies and are particularly hard to expunge.

Another can use is to keep an eye on particularly vulnerable packages, which can be dropped in favor of alternatives with a better security track record (e.g. gcj over openjdk, chromium over webkit).

Failing the above, one could use any remaining motivation along with debsecan to determine which packages one wants to fix themselves; preferably followed by uploading that fix to something like debian-mentors [0] so that every debian user can take advantage of that good work.

And maybe one day that work results in becoming a debian developer, as in my particular experience.

[0] http://mentors.debian.net

Keeping administrators up to date

Posted Jan 18, 2013 14:16 UTC (Fri) by mirabilos (subscriber, #84359) [Link]

I’d not use debsecan, for the same reason I reject apt-listchanges and the likes:

I don’t want to get several hundred mails, with mostly the same information, and some added in half of them.

There must be some tool to merge them first, without needing any user interaction, so a resulting total document will be mailed to me.

Keeping administrators up to date

Posted Jan 18, 2013 15:01 UTC (Fri) by ortalo (guest, #4654) [Link] (2 responses)

Could you elaborate on the distinction you make between these kind of tools and classical vulnerability scanners or security assessment tools, like http://www.openvas.org/ or http://oval.mitre.org/ ?
Maybe those tools could be more integrated in a distribution (easier to install and setup), that's true.
Another approach is (once again ;-) àla OpenBSD: /etc/security is a shell script run everyday to spot known problems and mail root.

However, IMHO, none of those tools will, for the moment, be smart enough to actually convince an otherwise busy and reluctant administrator to spend *more* time on securing something. That's an uphill battle IMO. I'd rather spend that time preventing unsecure packages to enter the distribution in the first place. (Yep, I confess: I am a potential customer for a debiansec/ variant; and even potentially willing to help.)

Keeping administrators up to date

Posted Jan 19, 2013 3:00 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

OpenVAS/etc are completely different to debsecan. They actively scan for potential issues. debsecan just takes a database of CVEs and matches them against installed packages. Similar to rc-alert, which sends mail about release-critical bug reports or wnpp-alert, which warns about orphaned packages.

OpenVAS and an OVAL interpreter are available in Debian.

If you would like to help make Debian more secure, check out these links:

http://security-tracker.debian.org/tracker/data/report
http://www.debian.org/security/audit/
http://www.debian.org/doc/manuals/developers-reference/pk...
http://www.debian.org/security/

Keeping administrators up to date

Posted Jan 23, 2013 14:38 UTC (Wed) by ortalo (guest, #4654) [Link]

Thanks for the pointers, I'll check them carefully. Really.

"OpenVAS/OVAL/co. are completely different from debsecscan"... from a security-oriented perspective: okay, but otherwise, I am not so sure.

If you have a security-oriented administrator, the distinction really matters (especially for an audit). However, he has already paid attention to both tools output and has probably already done enough to secure/audit the system. For him, the problem is more to assist in managing the tools output (especially over time) in order to get proper credit for his security work. (It would probably be nice too to have some evidence that unfixed issues are due to external causes; at least to neutralize liability where it matters.) And combine with intrusion detection too. (Starts to get a big thing, fortunately, you have a security administrator there to help...)

The average administrator may not make so much distinction between OpenVAS and debsecscan; he will take whatever tool is easier for him and the less intrusive (probably debsecscan then). However, he will need results carefully targetted at its level of knowledge and availability and very well justified (ie.: this is critical, really, or this is extremely easy, really).

IMHO, none of the tools adequately fills one of the two niches. One problem I see is that a third niche (regular administrator with time for security-oriented work) may simply not exist. However, many of our tools seem to work for that niche; hence the flow of "read-click-and-forget" things with security in the last decade, with their (predictable) cohort of "forgot to click" issues (along with "never reading anyway" or the rarer "read it all until late at night and then left in a hurry without clicking").

Keeping administrators up to date

Posted Jan 19, 2013 2:49 UTC (Sat) by pabs (subscriber, #43278) [Link] (2 responses)

debsecan itself needs more work, check out the bug tracker and git repository if you want to help out:

http://bugs.debian.org/debsecan
http://git.enyo.de/fw/debian/debsecan.git

Keeping administrators up to date

Posted Jan 20, 2013 14:58 UTC (Sun) by bernat (subscriber, #51658) [Link] (1 responses)

Florian seems uninterested in any improvement in debsecan. I am still waiting for it to handle backports in a sensible way:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470065

Keeping administrators up to date

Posted Jan 21, 2013 9:26 UTC (Mon) by pabs (subscriber, #43278) [Link]

I've personally be able to get him to apply one (admittedly small) patch. Maybe he just is busy and needs a ping, along with a suggestion to move debsecan to team maintenance. Could you send that, CC me if you want?