Probe emission in fstack-clash-protection

Probe emission in fstack-clash-protection

[Varun Kumar E]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Hello,

https://godbolt.org/z/P3M8s8jqh
The above case shows that gcc first decreases the stack pointer and then
probes.

As mentioned by Jeff Law (reference
<https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>)
under "More issues with -fstack-check". If an asynchronous signal is
received between the decrement of stack pointer and probing of the pages.
*"In that case, the stack pointer could be pointing beyond the guard into
the heap. The signal arrives and the kernel transfers control to the
registered signal handler. That signal handler is then running while its
stack is pointing into the heap. Thus, the attacker has clashed the stack
and heap, and there's a reasonable chance they can gain control over the
program" *

So, Shouldn't we first probe and if successful only then update the stack
pointer? Or Maybe I have understood it incorrectly.

regards,
Varun

Re: Probe emission in fstack-clash-protection

[Jeff Law]

On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
> Hello,
> 
> https://godbolt.org/z/P3M8s8jqh
> The above case shows that gcc first decreases the stack pointer and then
> probes.
> 
> As mentioned by Jeff Law (reference
> <https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>)
> under "More issues with -fstack-check". If an asynchronous signal is
> received between the decrement of stack pointer and probing of the pages.
> *"In that case, the stack pointer could be pointing beyond the guard into
> the heap. The signal arrives and the kernel transfers control to the
> registered signal handler. That signal handler is then running while its
> stack is pointing into the heap. Thus, the attacker has clashed the stack
> and heap, and there's a reasonable chance they can gain control over the
> program" *
> 
> So, Shouldn't we first probe and if successful only then update the stack
> pointer? Or Maybe I have understood it incorrectly.

That may ultimately be better for -fstack-check to make it more robust, 
but it still wouldn't be a viable alternative for stack clash protection 
for the reasons laid out in that blog post.

jeff

Re: Probe emission in fstack-clash-protection

[Eric Botcazou]

> That may ultimately be better for -fstack-check to make it more robust,
> but it still wouldn't be a viable alternative for stack clash protection
> for the reasons laid out in that blog post.

Well, -fstack-check does that when it's possible, e.g. on Windows, but it's 
not on x86[_64]/Linux where you *cannot* probe below the stack pointer.

-- 
Eric Botcazou

Re: Probe emission in fstack-clash-protection

[Florian Weimer]

* Varun Kumar E. via Gcc:

> Hello,
>
> https://godbolt.org/z/P3M8s8jqh
> The above case shows that gcc first decreases the stack pointer and then
> probes.
>
> As mentioned by Jeff Law (reference
> <https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>)
> under "More issues with -fstack-check". If an asynchronous signal is
> received between the decrement of stack pointer and probing of the pages.
> *"In that case, the stack pointer could be pointing beyond the guard into
> the heap. The signal arrives and the kernel transfers control to the
> registered signal handler. That signal handler is then running while its
> stack is pointing into the heap. Thus, the attacker has clashed the stack
> and heap, and there's a reasonable chance they can gain control over the
> program" *
>
> So, Shouldn't we first probe and if successful only then update the stack
> pointer? Or Maybe I have understood it incorrectly.

Let me rephrase a bit.  The caller has asserted that (%rsp) is valid
upon entry to the function because that's where the return address is
stored.  That means that (%rsp - 4096) is still in the guard page, so
the subsequent probe works.  But the kernel fault handler will not write
to that location because it has to protect the return address and the
red zone, so the first location used is (%rsp - 4096 - 8 - 128) or
thereabouts.

Jeff, this looks like a real bug to me.  It doesn't affect the main
thread on GNU/Linux because the kernel uses more than one page for the
guard area.  However, glibc uses exactly one page.  We could change that
to two pages on x86-64 at least without ill effects, I believe.  Or fix
GCC's probing to account for the red zone.

Thanks,
Florian