[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170621214006.GB28151@localhost.localdomain>
Date: Wed, 21 Jun 2017 14:40:06 -0700
From: Qualys Security Advisory <qsa@...lys.com>
To: oss-security@...ts.openwall.com
Subject: Re: Qualys Security Advisory - The Stack Clash
Hi Solar, all,
Thank you very much for this constructive feedback. For the sake of
transparency and an improved disclosure process in the future, we will
do the same now, and also address some of the concerns that have been
expressed since Monday.
But first, we would like to thank everyone who was involved in this
disclosure, for their hard work and patience, and especially Solar for
creating and administering the mailing-lists that made it possible (and
for accepting, although reluctantly, the embargo extension).
On Mon, Jun 19, 2017 at 10:39:33PM +0200, Solar Designer wrote:
> The stated argument for extending the embargo duration beyond list
> policy's maximum was that fixes presumably wouldn't be ready.
This was not the only reason why we eventually decided to extend the
embargo; here is what we wrote in an e-mail to distros@, on May 28:
"""
The discussions that
took place here on distros eventually forced us to extend the embargo
from the original CRD (May 30) to June 19:
- there are serious problems with the two solutions that we proposed
("Increase the size of the stack guard-page" and "Recompile all
userland code with GCC's -fstack-check option");
- please see Red Hat's analysis, attached;
- when we asked here if distros would be ready by May 30, only three
answered (two "yes", one "no"), and hoping for the best ("the ones who
did not answer will surely be ready") was not an option, and "let's
publish anyway on May 30, distros should have been ready" was not an
option either (the end users would be the ones suffering from such a
debacle).
"""
The first problem was that 1MB is not enough on all architectures; the
second problem was that -fstack-check does not always "touch" all pages;
and Red Hat's analysis was an extensive report about the fixes needed in
the kernel, the glibc, and gcc.
All of this, plus the third reason mentioned above, and our own
assessment of the situation, helped us make our decision to extend the
embargo.
> I understand
> it's rare for companies to do quality security research, and I didn't
> want my action to have hampered the stream of quality security research
> we're seeing from Qualys lately.
Thank you very much. However, we must admit that this coordinated
release has been one of the most stressful and painful experiences we
ever had: we were torn between those who wanted to publish early and
those who wanted to publish later, and in the middle of all this
coordination we were trying to complete our research (we had not
successfully exploited 64-bit Linux yet when we first contacted
distros@).
Such a responsible disclosure could have been, and should have been,
easier and simpler, even with so many vendors involved. How could such
a situation be handled better next time? We are open to suggestions.
Finally, we would like to address a concern that has been voiced by
Chris Evans (who has also quoted Solar's mail, thus answering here):
"""
There's also the question of whether "customers" get access to details
before patches are available
"""
Absolutely not: we have not shared a single detail of these
vulnerabilities with anyone outside of Qualys before the Coordinated
Release Date; and even within Qualys, we have kept this
compartmentalized until the very end.
Thank you very much!
With best regards,
--
the Qualys Security Advisory team
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.
