Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jun 2017 17:27:43 -0400
From: Brad Spengler <>
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).
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:
> 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 ):
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.


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.