oss-sec mailing list archives
Re: Qualys Security Advisory - The Stack Clash
From: Jeff Law <law () redhat com>
Date: Wed, 21 Jun 2017 16:48:14 -0600
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=specificAnd 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
Current thread:
- Re: Qualys Security Advisory - The Stack Clash, (continued)
- Re: Qualys Security Advisory - The Stack Clash Daniel Micay (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Brad Spengler (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Mike O'Connor (Jun 22)
- Re: Qualys Security Advisory - The Stack Clash Solar Designer (Jun 24)
- Re: Qualys Security Advisory - The Stack Clash Jeff Law (Jun 23)
- Re: Qualys Security Advisory - The Stack Clash Kurt Seifried (Jun 23)
- Re: Qualys Security Advisory - The Stack Clash Solar Designer (Jun 24)
- Re: Qualys Security Advisory - The Stack Clash Qualys Security Advisory (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash PaX Team (Jun 21)
- Re: Qualys Security Advisory - The Stack Clash Jeff Law (Jun 21)