Bug 1037551

Note Qualys suggests the CRD to be pushed back to

CRD: 2017-06-19

This needs to be confirmed by Solar Designer who operates the distros list.

CRD was confirmed and is now:

CRD: 2017-06-19

This issue is now public:


https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Now that this is public, maybe we should also start talking about a full fix. While discussing this on the security@kernel.org, Linus has mentioned that the stack gap in the kernel will always be just a workaround. And I fully agree with him. Currently we believe/hope that no reasonable suid binary does larger than 256 pages alloca/VLAs. This might be right for now but it can change in future.

He was proposing that a compiler could help in this regards considerably and basically probe alloca/VLAs in PAGE_SIZE units which would basically remove all unexpectedly large stack jumps. I am not sure anybody from the gcc comunity is working on that but I would like to pull our gcc people and ask them about their opinion. I can expect that this could kill the performance for some benchmarks but I guess an opt-in approach should be much less controversial. We could use an option in all packages which build/install suid binaries in our distribution over time.

Thoughts?

(In reply to Michal Hocko from comment #11)
> He was proposing that a compiler could help in this regards considerably and
> basically probe alloca/VLAs in PAGE_SIZE units which would basically remove
> all unexpectedly large stack jumps. I am not sure anybody from the gcc
> comunity is working on that but I would like to pull our gcc people and ask
> them about their opinion. I can expect that this could kill the performance
> for some benchmarks but I guess an opt-in approach should be much less
> controversial. We could use an option in all packages which build/install
> suid binaries in our distribution over time.

As mentioned in the published advisory, gcc's '-fstack-check' option would probably be the best way to go.

This is tracked in bug 1039513.

Basically the compiler people are working on an enhanced -fstack-check version. test patches are available, but given the complexity of them I fear it might be some more days until they are ready.

(In reply to Michal Hocko from comment #11)
> He was proposing that a compiler could help in this regards considerably and
> basically probe alloca/VLAs in PAGE_SIZE units which would basically remove
> all unexpectedly large stack jumps. I am not sure anybody from the gcc
> comunity is working on that but I would like to pull our gcc people and ask
> them about their opinion. I can expect that this could kill the performance
> for some benchmarks but I guess an opt-in approach should be much less
> controversial. We could use an option in all packages which build/install
> suid binaries in our distribution over time.

Yes, the compiler people are looking at this.  -fstack-check (available since a long time) is doing something like this, but not quite, in particular it tries
to save time by some mechanisms that could conceivably be exploited by
malicious code (it was designed for something else than security).  We're
working on implementing a different mode to that which does the obvious per-page
probing.

we implemented -fstack-clash-protection in SLE15 / 15.0 and newer for all binaries.

Also in all updates for SLES 12 SP2 onwards.