Secure testing team - Jul 2007 - Vulnerabilities not affecting Debian: reporting proposal

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

Alexander Konovalenko wrote:
> Proposed solution
Do you know about

http://www.debian.org/security/nonvulns-etch

Regards,

	Joey
http://www.debian.org/security/nonvulns-sarge

-- 
It''s time to close the windows.

On 7/11/07, Martin Schulze <joey at infodrom.org>
wrote:
>
> Do you know about
>
> http://www.debian.org/security/nonvulns-etch
Oh, that''s great. I should have read the website more carefully!
Thanks.

What about providing a more elaborate summary for some issues? Some
entries merely say that the bug is not exploitable or that Debian is
not affected.

Regards,
  Alexander

Alexander Konovalenko wrote:
> On 7/11/07, Martin Schulze <joey at infodrom.org> wrote:
>>
>> Do you know about
>>
>> http://www.debian.org/security/nonvulns-etch
>
> Oh, that''s great. I should have read the website more carefully!
Thanks.
>
> What about providing a more elaborate summary for some issues? Some
> entries merely say that the bug is not exploitable or that Debian is
> not affected.
Feel free to add (or adjust the output format).
Should be discussed with the web team I guess (debian-www at lists...)

Regards,

	Joey


-- 
It''s time to close the windows.

Hi,

Alexander Konovalenko wrote:
> 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.
do you know the web interface to these svn commits at 
http://security-tracker.debian.net/tracker ? If you already have the 
CVE id, you can easily get all the information there. The 
explanations for not-affected could be more verbose sometimes, but I 
think in general they are sufficient.

There is no feed for this information, but if you want to be 
up-to-date about the packages you use, you should look at the 
debsecan package (though that does not give you information about 
non-issues).

Cheers,
Stefan

Alexander Konovalenko on 2007-07-11 16:59:00 +0400:
> 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.
[...]
> 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.
I can''t speak for the security team, but the testing security team
could
always use more people doing what you apparently already do - determine
which new CVEs affect Debian and find ways to get those issues fixed.
Head over to http://security-tracker.debian.net/tracker/data/report to
find out how you can contribute.

Much of the infrastructure you mentioned is already in place.  The
testing security team keeps a list of CVEs and short descriptions of how
(if at all) each affects Debian as well as information like versions in
which the issue is fixed, bug numbers, and severity indicators.  It''s
kept in plain-text in a publicly-viewable svn repository, but there are
other ways to view the information.  At
http://security-tracker.debian.net/ you can look up the status of
different packages, CVEs, and security bug numbers.  Also, the Debian
Security Analyzer (package debsecan) will alert you to vulnerable
packages on that system using the security-tracker data.

On 7/11/07, Alec Berryman <alec at thened.net>
wrote:
>
> I can''t speak for the security team, but the testing security team
could
> always use more people doing what you apparently already do - determine
> which new CVEs affect Debian and find ways to get those issues fixed.
Actually I''m not currently following recent vulnerabilities, sorry...
I just wanted to suggest a useful feature that could help others now
and also myself in the future.
> Much of the infrastructure you mentioned is already in place.  The
> testing security team keeps a list of CVEs and short descriptions of how
> (if at all) each affects Debian as well as information like versions in
> which the issue is fixed, bug numbers, and severity indicators. 
It''s
> kept in plain-text in a publicly-viewable svn repository, but there are
> other ways to view the information.  At
> http://security-tracker.debian.net/ you can look up the status of
> different packages, CVEs, and security bug numbers.  Also, the Debian
> Security Analyzer (package debsecan) will alert you to vulnerable
> packages on that system using the security-tracker data.
Thanks for the information, it''s really helpful.

  -- Alexander