[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jun 2017 17:27:43 -0400
From: Brad Spengler <spender@...ecurity.net>
To: oss-security@...ts.openwall.com
Subject: Re: Qualys Security Advisory - The Stack Clash
> 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
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
