[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jun 2017 17:30:22 -0600
From: Jeff Law <law@...hat.com>
To: oss-security@...ts.openwall.com, Qualys Security Advisory <qsa@...lys.com>
Subject: Re: Qualys Security Advisory - The Stack Clash
On 06/21/2017 03:40 PM, Qualys Security Advisory wrote:
>
> 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.
And just one data point here. We (Red Hat) had hoped to be able to drop
in a compiler update with an improved -fstack-check and rebuild at least
glibc with that compiler.
However, the further we dug, the more significant problems we found,
particularly as we started looking at other architectures.
As late at June 8, we were still internally debating the pros/cons of
updating GCC and rebuilding GLIBC with the new compiler, even if only
certain platforms were covered. The ultimate decision was to play it
safe and defer integration of the GCC work to a later update.
The embargo extension may have been painful, but it gave us the time to
look deeply at the GCC situation and come to a well reasoned technical
conclusion.
Had we done forward in May per the original schedule we well could have
made an incorrect technical decision under the significant time
pressure. The consequences of getting that decision wrong are
potentially greater than the impact of this particular security issue.
That would also have put other distros that use GCC at as disadvantage
as the in-progress GCC bits were not "upstream ready" and thus would
have been dropped into Red Hat's GCC sources which would likely have
been fairly difficult for other distros that use GCC to consume.
>
> 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.
Understood and thanks for evaluating the situation as a whole and coming
to a well reasoned decision WRT the embargo.
--
I don't speak for anyone but myself, but I strongly believe in making
reasonable, rational decisions based on the best information available
rather than following policy blindly. Don't get me wrong, policy is
important as it often encodes years of hard learned lessons and often
policy is a good default position.
>
>> 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@).
Understood. I'd like to point out that knowing 64bit exploits had not
been completed, but looked reasonably possible was very helpful in our
internal discussions about the breadth of the problem.
And more generally thanks for all the work in this space! Don't ever
hesitate to contact me with any questions/concerns WRT GCC's code
generation in this space or others.
jeff
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.
