bug#27429: Stack clash (CVE-2017-1000366 etc); -fstack-check

[Leo Famulari]

I agree, let's wait for guidance from the upstream GCC and GLIBC developers.


 Original Message 
From: Marius Bakke <mba...@fastmail.com>
Sent: June 25, 2017 6:41:06 AM EDT
To: Danny Milosavljevic <dan...@scratchpost.org>, 27...@debbugs.gnu.org
Subject: bug#27429: Stack clash (CVE-2017-1000366 etc); -fstack-check

Danny Milosavljevic <dan...@scratchpost.org> writes:

> Hi,
>
> what do you all think of rebuilding the world with "-fstack-check" (either 
> now or later on) ?
>
> That would make gcc emit code to always grow the stack in a way that it 
> certainly touches each 4 KiB (parametrizable by 
> STACK_CHECK_PROBE_INTERVAL_EXP) page on the way.
>
> I think that would be the right and permanent fix - unlike the whack-a-mole 
> approach where we patch programs not to do what they are supposed to do, if 
> their stack allocation happens to grow.
>
> See also <https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt> and 
> <https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html>.

Red Hat investigated this during the embargo[0] and found that the
current implementation in GCC has problems[1]. We should wait until
those issues are resolved first, but sounds good to me.

[0] http://seclists.org/oss-sec/2017/q2/556
[1] http://seclists.org/oss-sec/2017/q2/505

bug#27429: Stack clash (CVE-2017-1000366 etc); -fstack-check

[Marius Bakke]

Danny Milosavljevic  writes:

> Hi,
>
> what do you all think of rebuilding the world with "-fstack-check" (either 
> now or later on) ?
>
> That would make gcc emit code to always grow the stack in a way that it 
> certainly touches each 4 KiB (parametrizable by 
> STACK_CHECK_PROBE_INTERVAL_EXP) page on the way.
>
> I think that would be the right and permanent fix - unlike the whack-a-mole 
> approach where we patch programs not to do what they are supposed to do, if 
> their stack allocation happens to grow.
>
> See also  and 
> .

Red Hat investigated this during the embargo[0] and found that the
current implementation in GCC has problems[1]. We should wait until
those issues are resolved first, but sounds good to me.

[0] http://seclists.org/oss-sec/2017/q2/556
[1] http://seclists.org/oss-sec/2017/q2/505


signature.asc
Description: PGP signature

bug#27429: Stack clash (CVE-2017-1000366 etc); -fstack-check

[Danny Milosavljevic]

Hi,

what do you all think of rebuilding the world with "-fstack-check" (either now 
or later on) ?

That would make gcc emit code to always grow the stack in a way that it 
certainly touches each 4 KiB (parametrizable by STACK_CHECK_PROBE_INTERVAL_EXP) 
page on the way.

I think that would be the right and permanent fix - unlike the whack-a-mole 
approach where we patch programs not to do what they are supposed to do, if 
their stack allocation happens to grow.

See also  and 
.

Note that the kernel itself has to put argv and envp into the user process' 
stack and this can already make the very first stack allocation that a process 
does in its main() need to grow the stack, and reach across the guard page.  So 
the right fix is to just make the stack allocations never reach across the 
guard page without using it.