Date: Mon, 4 Mar 2013 05:44:38 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) On Wed, Feb 27, 2013 at 07:26:39PM +0100, Petr Matousek wrote: > Greg, FYI. The linux-distros mailing list has strict rules about the > maximum embargo period. It is ~14 days. I hope that ~14 days are > acceptable as a grace period for you when the commit goes public. At the > end of the embargo period the info is always sent to oss-sec with CVE id > assigned. > > Also, Alexander, are you willing to accept the semi-public nature of the > sko submissions to linux-distros and treat them as embargoed even though > the commit is already public? > > For me, this solutions is not optimal as we usually treat any issue that > has public commit as public one, but it would at least avoid > CVE-2013-0871 like problems. It's a tradeoff that I would rather not be making because it's primarily a workaround for the difference of opinion between linux-distros and sko folks. Also, it's not just me. Is everyone on linux-distros OK with treating the partially public issues that would be coming from sko as embargoed? And for how long? If a certain linux-distros member is not OK with that, it's a reason to decline sko's offer, not to unsubscribe that member - well, or to start a separate list with a subset of linux-distros members who are OK with treating sko issues specially. I think that, if all linux-distros members agree, we may choose to give a shorter grace period to issues disclosed to linux-distros from sko, for which fixes have already been committed publicly (just not fully documented as security). I think that allowing up to ~14 days is too much for these. What grace period would be reasonable? Here's one way to look at it: would we provide any grace period, and how much, in case an issue brought to linux-distros is fixed in the upstream author's public repository before the CRD? Not necessarily a Linux kernel issue, but in general. My guess, from past experience (including vendor-sec), is that we might reasonably provide a grace period of a couple of days. Now, if we make this literally 2 days only, it won't be enough time for the larger distro vendors' QA. For Red Hat this is probably less of an issue since a Red Hat person will be on sko. For other larger distro vendors it is probably a serious issue, making these "two days in advance" notifications nearly useless. For some smaller distro vendors, these notifications would probably be helpful. Can we do more than 2 days? Maybe 7? What exactly will be happening during this time? Are distros free to commit their own fixes, just not announce them as security yet (mimic the Linux kernel's approach), or do they have to knowingly accept the elevated risk that someone will figure out the vulnerability (from upstream's commit) and start exploiting it on the users' systems? Either is arguably negligent towards the users: not informing them that they need to upgrade for security vs. not providing such upgrades yet. Maybe a less unethical workaround to sko's policy would be for distros to explicitly state that an update is for security, but not to provide any detail until the grace period (of a few days?) is over. Unfortunately, this makes sko's approach even more ridiculous, almost killing its purported advantages. (Of course, all of these approaches have been known for decades.) In my opinion, it'd be best if Linus, Greg, et al. would reconsider their approach. Since this is unlikely to happen, the question is whether there's a reasonable workaround that we can use to mitigate the impact, without introducing other issues that would be as bad (or worse). From a purely technical perspective, perhaps accepting sko's notifications to linux-distros and giving a grace period may help reduce the number of systems compromised per year (although we'll never know it reliably). In this respect, not going for it may be unethical. On the other hand, going for it is unethical in other ways as I described above. Overall, I think we should bite the bullet and accept sko's notifications to linux-distros, with a grace period of up to 7 days. Whenever a distro is ready to release an update, they should be able to insist on doing so within another 1 day, even if the initially planned grace period would expire later. Would sko be OK with this? Greg? Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.