oss-sec mailing list archives
Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow)
From: Michael Gilbert <mgilbert () debian org>
Date: Sun, 3 Mar 2013 22:39:30 -0500
On Sun, Mar 3, 2013 at 9:12 PM, Greg KH wrote:
On Mon, Mar 04, 2013 at 05:44:38AM +0400, Solar Designer wrote:In my opinion, it'd be best if Linus, Greg, et al. would reconsider their approach.Reconsider just what specifically? You bring up a bunch of issues that the distros need to consider, what can the Linux kernel security team do differently? We were asked to notify the linux-distro list, and now we will be doing that. Should we not and just go back to how things were before?
Please reconsider the quasi-secret denial state that has been the kernel security posture for the past 20 years: i.e. the persistent inability to recognize that the existing approach serves to do more harm than it does good. Argument supporting that idea follows. Malicious actors/organizations (the bad guys) have resources, skill, time, and most importantly motivation (i.e. profit) to be able to study a sufficient subset of all kernel commits to be able to find a few that provide them the avenue they need to achieve their malevolent goals. The good guys have none of those. They have day jobs, have to produce new code (rather than reviews) most of the time, have tons of other bugs to deal with, and most importantly have no monetary incentive to sit there and study every kernel commit message/patch. Instead, the good guys rely on a system of trust and generosity, which seems to be working fairly well on oss-sec in general, but definitely not with the kernel-land. The persistent secrecy is in direct opposition to trust, and refusals to spend the little time to write blurbs about issues is a disservice to users (an ungenerous act), who if they were in the know, could use that information to be able to solve those problems on their own (note that's often done by a distro kernel-sec team). And of course there is that other kicker, the bad guys only need discover a few bugs. The good guys need to find (and fix) them all, and that requires information. By keeping that information in this quasi-secret state, you are guaranteeing a certain (large subset) of users remain in the dark while some of the malevolent actors are in the light. That is wrong. I was getting encouraged by the recent anger-centric posts, the "what is it that we're supposed to do better?" ones. That gave me some encouragement that there was the possibility of positive change, but the "we're not going to make users more unsafe by telling them about issues affecting them" is a persistence of the denial state. That logic completely violates the known idiom that knowledge is power: give users the knowledge that they need to protect themselves, and they will; starve them of that knowledge, and they remain vulnerable. Best wishes, Mike
Current thread:
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow, (continued)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Greg KH (Feb 27)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Petr Matousek (Feb 27)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Greg KH (Feb 27)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Eugene Teo (Feb 28)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Petr Matousek (Feb 27)
- Re: CVE request - Linux kernel: VFAT slab-based buffer overflow Greg KH (Feb 27)
- handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Solar Designer (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Greg KH (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Solar Designer (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Greg KH (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Michael Gilbert (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Greg KH (Mar 03)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Eric Lacombe (Mar 04)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Greg KH (Mar 04)
- Re: handling of Linux kernel vulnerabilities Kurt Seifried (Mar 04)
- Re: handling of Linux kernel vulnerabilities Solar Designer (Mar 04)
- Re: handling of Linux kernel vulnerabilities Noel Butler (Mar 05)
- Re: handling of Linux kernel vulnerabilities Solar Designer (Mar 05)
- Re: handling of Linux kernel vulnerabilities Alton Moore (Mar 05)
- Re: handling of Linux kernel vulnerabilities (was: CVE request - Linux kernel: VFAT slab-based buffer overflow) Eric Lacombe (Mar 05)
- Re: handling of Linux kernel vulnerabilities Andreas Ericsson (Mar 04)