[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal

[Alexander Konovalenko]

I would like to propose that Debian security teams publish a short
report each time they review a vulnerability in a program that's
included in Debian and find that the vulnerability does *not* affect
Debian.

Problem description

When I maintain a secure machine, I naturally want to keep it secure
against known attacks. I subscribe to Bugtraq and a CVE-compatible
vulnerability database and watch them closely for anything that could
affect my machine. When an advisory that potentially affects my
machine is published, I try to react appropriately before it is fixed
in the distribution (for our purposes here, the distribution is either
Debian stable or testing), and then I look forward for the
distribution to issue a patch.

However, sometimes the time passes, but there is still no security
update from the distribution. What's up? Has the security team read
the advisory or did they miss it somehow? Maybe they found that the
versions they maintain aren't vulnerable? Are they still working on a
fix? Are they waiting for other distributions to complete the QA of
their patches?

When such a delay occurs, I basically have three options: 1) hope that
the vuln doesn't affect my distribution or will be patched real soon
now; 2) do my own research: determine if it affects my versions of
software, and if yes, try to port patches from other distributions or
from upstream, etc.; 3) disable the program/service entirely. I can't
let my machine have a publicly known security hole for too long. Note
that doing my own research is only feasible when the details of the
bug have already been published.

The problem is with investigating the vulnerability independently. I'm
not an expert and have other things to do. Determining whether my
distribution is affected by a bug is not trivial. It's not enough to
try a published exploit or compare the relevant part of the source.
Without a deeper understanding of the vulnerability and its context, I
can't tell whether the exploit doesn't work because my version is
immune or because the exploit should be modified slightly for my
version. And all that is just duplicate effort: the security team has
most certainly done the same research more accurately than I could
ever do.


Proposed solution

I suggest establishing two CVE-compatible lists of vulnerabilities
that could potentially affect Debian stable or testing but were found
otherwise by the corresponding security team. Each team will manage
its own list. Vulnerabilities that "potentially affect" Debian are
those which make a sysadmin reading the advisory wonder if her box is
vulnerable.

Each entry should minimally include the following:

 * potentially affected Debian packages: their names and versions
  * all relevant CVE references
 * a short explanation why those packages are not affected

More information that can help verify that the packages are immune
will be helpful. It should be possible to subscribe to new entries (a
mailing list or an RSS/Atom feed would suffice).

This will keep Debian users more informed about the status of known
vulnerabilities in Debian and help them manage their systems.


Security impact of the proposed solution

If the disclosure is coordinated with other organizations, telling why
Debian is not affected could prematurely reveal the details of the
vulnerability. There are two options to handle this: 1) wait until the
full disclosure and then publish the "non-advisory"; 2) post a
preliminary report that only references the CVE number and update it
with the details on why it doesn't affect Debian later.

If the security team is in error and the Debian package is actually
vulnerable, releasing their wrong verdict won't help attackers much.
The attackers could gain some confidence that Debian would remain
vulnerable yet for some more time. On the other hand, white-hat
researchers would be able to verify the security team's decision more
easily. The benefits of public disclosure outweigh the risks here.

As for other distributions that *are* vulnerable, the disclosure of
the reasons why Debian is not doesn't help attackers either, provided
they already know the vulnerability details.


Implementation

Minimal amount of extra work is required. The security team will have
all necessary information by the time when a report should be
published. It is just a matter of setting up a mailing list or a feed
and posting to it whenever a potential vulnerability is revised.


Existing solutions

I couldn't find any existing solutions to the problem described above.
The testing security team does publish some of the information in
their Secure-testing-commits, but it lacks more verbose explanations
and is more of a tool for team members than a source of information
intended for the general public like Debian Security Advisories.


I'm not sure where is the appropriate place to discuss this. I guess
posting your replies to debian-security at lists.debian.org will reach
the widest audience, which is desirable.

 -- Alexander