Security [LWN.net]

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.

Comments (12 posted)

Brief items

Security quotes of the week

When we mere imperfect mortals deem to pit even our most righteous beliefs against the timorous gods of old, it is simultaneously an act of faith and the voluntary assumption of enormous risk, for the gods of obsolescence still possess mighty powers indeed.

In the end, the old gods of information scarcity and control will indeed die, and more open models will win the future.

-- Lauren Weinstein

This vulnerability was different in that it was an 0day (and has been for some time) inside all the major malware dropper kits. And yet, no massive screaming has really been reported. People aren't really [panicking]. Just the same advice - boring even to people in the security industry. You have to wonder - is the level of public infection so high that something this pervasive doesn't move the needle?

-- Dave Aitel

That is to say, The Dictator's Practical Internet Guide to Power Retention's main value is not for dictatorships at all; it is written for us, citizens of the free world, as a wake up call against the various stakeholder that wish to subdue the Internet away from us. Be it ACTA, TPP, SOPA, National Security Inquiry, Patriot Act or just your average copyright industry demand, our Internet is always in danger – and thus our freedom is as well.

-- Moshe Reuveni reviews The Dictator's Practical Internet Guide to Power Retention

The larger story here is that as more of our communications move to mobile devices and to the cloud, we will encounter surprising exceptions to our expectations for secure communications. Browsers like Nokia Xpress and Opera Mini are essentially moving our web browsing to the cloud—pushing the security functions that we traditionally thought existed in a safe zone within our device to far-away servers. At the same time, our devices can betray us by aiding and abetting this security offloading.

-- Steve Schultze on mobile browsers decrypting SSL

Comments (2 posted)

New vulnerabilities

389-ds-base: ACL restriction bypass

Package(s):

389-ds-base

CVE #(s):

CVE-2012-4450

Created:

January 15, 2013

Updated:

March 11, 2013

Description:

From the CVE entry:

389 Directory Server 1.2.10 does not properly update the ACL when a DN entry is moved by a modrdn operation, which allows remote authenticated users with certain permissions to bypass ACL restrictions and access the DN entry.

Alerts:

Fedora	FEDORA-2012-20156	2013-01-15
Red Hat	RHSA-2013:0503-03	2013-02-21
Oracle	ELSA-2013-0503	2013-02-25
Scientific Linux	SL-389--20130228	2013-02-28
CentOS	CESA-2013:0503	2013-03-09

Security

Keeping administrators up to date

Security quotes of the week

389-ds-base: ACL restriction bypass

asterisk: denial of service

autofs: denial of service

conga: leaks authentication credentials

drupal7-context: information disclosure

freeciv: denial of service

java: multiple vulnerabilities

kde-filesystem: insecure build flags

kexec-tools: executable stack

mozilla: cross-site scripting

mysql: authentication bypass

OpenIPMI: invalid permissions

pl: code execution

proftpd-dfsg: privilege escalation

qemu: buffer overflow

qt: confusing SSL error messages

rails: code execution and more

rubygem-activerecord: sql injection

tcl-snack: code execution