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@lists.debian.org will reach the widest audience, which is desirable. -- Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]