[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jun 2017 16:48:14 -0600
From: Jeff Law <law@...hat.com>
To: oss-security@...ts.openwall.com, PaX Team <pageexec@...email.hu>,
Agostino Sarubbo <ago@...too.org>
Subject: Re: Qualys Security Advisory - The Stack Clash
On 06/21/2017 03:29 PM, PaX Team wrote:
> On 21 Jun 2017 at 10:22, Jeff Law wrote:
>
>> On 06/21/2017 04:46 AM, Agostino Sarubbo wrote:
>>> On Monday 19 June 2017 08:28:43 Qualys Security Advisory wrote:
>>>> III. Solutions
>>>> - Recompile all userland code (ld.so, libraries, binaries) with GCC's
>>>> "-fstack-check" option, which prevents the stack-pointer from moving
>>>> into another memory region without accessing the stack guard-page (it
>>>> writes one word to every 4KB page allocated on the stack).
>>>
>>> For the record, Gentoo Hardened enables by default -fstack-check=specific
>> And if you were to look at the generated code, you'll see that it
>> happily skips 2-3 pages of probes in prologues as well as within alloca
>> spaces. It's a false sense of security.
>
> Gentoo Hardened uses the grsecurity kernel which enforces a 64kB heap-stack
> gap by default (it's also user adjustable). are you saying that the gcc
> probes are not sufficient to prevent jumping over that range?
With a 64k guard, you should be OK and protected. -fstack-check will
consistently skip 8218 bytes on x86 (8192 on most architectures). Even
if you combined the skipped space from the prologue and the skipped
space in the dynamic area, you're only at just over 16k -- and it's not
clear the two skipped areas could be combined like that anyway.
Given the larger guard you should be in good shape. Sorry to have
sounded alarmist without having full information about your
configuration, particularly WRT the expanded guard page.
--
There's one theoretical approach I'm aware of that one could use the
skip the guard in your situation. I'm not aware of any code in practice
that would have the right properties to trigger *and* triggering would
require a particular optimization that neither LLVM nor GCC perform to
the best my knowledge (nor are they likely to as the optimization would
not likely improve any hot path performance).
We'll be making that theoretical attack significantly harder to exploit
as part of the upstream GCC work around a new -fstack-check implementation.
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.
