Alexander Konovalenko
2007-Jul-11 12:59 UTC
[Secure-testing-team] 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
Martin Schulze
2007-Jul-11 13:11 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
Alexander Konovalenko wrote:> Proposed solutionDo 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.
Alexander Konovalenko
2007-Jul-11 13:42 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
On 7/11/07, Martin Schulze <joey at infodrom.org> wrote:> > Do you know about > > http://www.debian.org/security/nonvulns-etchOh, 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
Martin Schulze
2007-Jul-11 13:52 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
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.
Stefan Fritsch
2007-Jul-11 17:10 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
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
Alec Berryman
2007-Jul-11 17:27 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
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.
Alexander Konovalenko
2007-Jul-12 10:26 UTC
[Secure-testing-team] Vulnerabilities not affecting Debian: reporting proposal
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