oss-sec mailing list archives
Re: Qualys Security Advisory - The Stack Clash
From: Brad Spengler <spender () grsecurity net>
Date: Wed, 21 Jun 2017 17:27:43 -0400
OpenBSD isn't a member of the distros list - they were notified by Qualys separately. This matter was discussed, and some folks were unhappy about OpenBSD's action, but in the end it was decided that since, as you correctly say, the underlying issue was already publicly known, OpenBSD's commits don't change things much. Sure this draws renewed attention to the problem, but probably not to the extent and in the many specific ways the Qualys findings cover. So it was decided to keep the embargo on the detail.
Thank you for clarifying that, my assumption was indeed wrong then. Still, if OpenBSD was able to resolve the issues necessary after notification without leaking full details to the public, shouldn't this have been possible for the other projects without an embargo, let alone an extended one? Especially considering that the full duration of the extended embargo didn't result in complete fixes for the issue and in fact resulted in a broken fix for Linux, which could easily have been avoided if the discussions around it happened in public (and none of the deep details from the Qualys advisory would have been needed for any of those discussions). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89 for instance mentions Linus' fix blew up in 3 minutes of fuzz testing.
Ditto for the "move mmap_area and PIE binaries away from the stack" patch series posted to LKML and CC'ed to kernel-hardening on June 2: http://www.openwall.com/lists/kernel-hardening/2017/06/02/ which might have been inspired by Qualys work known to Red Hat engineers internally. A difference is that Red Hat is a member of the distros list. I brought this up on the distros list, and another Red Hat person said "We'll deal with this internally." Given the circumstances, I find this response satisfactory.
At first I was rather concerned about this, so I emailed Rik directly and asked him the simple question of whether the advance notice prioritized or kickstarted the process of porting those features, regardless of having looked at some code in the past (as I imagine much of our code has been looked at). I too am satisfied with his answer that the actual porting work on his part had already been done prior to that notice, and that any internal concerns afterward were simply to avoid the appearance of impropriety. My take on the embargoing process (outside of what's already mentioned on https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php ): I've always been concerned by the fact that smaller distros seem to be barred from distros-list membership; it seems the arrangement lends itself too much to enabling the marketing of the larger companies and in fact perhaps even disincentivizing their investment in security as the embargo process enables them to skirt much of the public pain they'd otherwise have to experience (for in this instance what was a completely avoidable problem). I get the practical reasons for the policy (increased leak risk, major distros often do the actual fixing work, etc) but from a level of principle it's always rubbed me the wrong way. So despite that I have full trust in you Alexander as being completely transparent and impartial despite having to engage in a bit of politics necessary to work with all the companies involved, I am uneasy (and I believe I note some uneasiness in your own mails) with how others are exploiting the arrangment despite your sincere efforts at sticking to the policies you established. That said, I think regardless of whether you head the distros list or not, the major companies are going to see it to be in their financial/PR interest to maintain an embargo list. I would not be surprised at all if were you to step down from the role/shutter the list, a company like Red Hat would quickly swoop in to "take the reins." Which would be a shame and adds to my general worries about the direction this industry is going in, since your record for fairness is sterling, and I doubt very much that dogged dedicated to transparency, fairness, and ethics would continue with anyone else at the helm. Thanks, -Brad
Attachment:
signature.asc
Description: Digital signature
Current thread:
- Re: Qualys Security Advisory - The Stack Clash, (continued)
- Re: Qualys Security Advisory - The Stack Clash Stuart Henderson (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash kseifried () redhat com (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Qualys Security Advisory (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Jeff Law (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Daniel Micay (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Florian Weimer (Jun 22)
- Re: Qualys Security Advisory - The Stack Clash Brad Spengler (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Solar Designer (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Daniel Micay (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Brad Spengler (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Mike O'Connor (Jun 22)
- Re: Qualys Security Advisory - The Stack Clash Solar Designer (Jun 24)
- Re: Qualys Security Advisory - The Stack Clash Jeff Law (Jun 23)
- Re: Qualys Security Advisory - The Stack Clash Kurt Seifried (Jun 23)
- Re: Qualys Security Advisory - The Stack Clash Solar Designer (Jun 24)
- Re: Qualys Security Advisory - The Stack Clash PaX Team (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Jeff Law (Jun 21)