The Stack Clash

This looks pretty brutal.<p>Quote from Kurt Seifried of RedHat <a href="http:&#x2F;&#x2F;www.openwall.com&#x2F;lists&#x2F;oss-security&#x2F;2017&#x2F;06&#x2F;19&#x2F;2" rel="nofollow">http:&#x2F;&#x2F;www.openwall.com&#x2F;lists&#x2F;oss-security&#x2F;2017&#x2F;06&#x2F;19&#x2F;2</a><p>&quot;<i>I just want to publicly thank Qualys for working with the Open Source community so we (Linux and BSD) could all get this fixed properly. There was a lot of work from everyone involved and it all went pretty smoothly.</i>&quot;<p>Debian security advisories rapid fire:<p>glibc <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00146.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00...</a><p>linux <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00148.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00...</a><p>exim4 <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00147.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00...</a><p>libffi <a href="https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00149.html" rel="nofollow">https:&#x2F;&#x2F;lists.debian.org&#x2F;debian-security-announce&#x2F;2017&#x2F;msg00...</a><p>And just a sample from the Qualys announcement (out of many more), &quot;local-root exploit against Exim&quot;, &quot;local-root exploit against Sudo (Debian, Ubuntu, CentOS)&quot;, &quot;local-root exploit against &#x2F;bin&#x2F;su&quot;, &quot;local-root exploit against ld.so and most SUID-root binaries (Debian, Ubuntu, Fedora, CentOS)&quot;, &quot;local-root exploit against &#x2F;usr&#x2F;bin&#x2F;rsh (Solaris 11)&quot;, as well as proof of concepts for OpenBSD, FreeBSD and so on.

That is a crazy number of CVEs. At a quick glace I am seeing a lot of local root exploits. Generally speaking if a attacker has an account on your system you are already hosed. But this doesn&#x27;t bode well for more vulnerabilities of this nature that don&#x27;t require local root.

I&#x27;m trying my hardest to understand how this is a novel problem. Maybe somebody can help me?<p>If I control the stack pointer and can write to where it points, I can write to arbitrary in process memory. Sure!<p>Is that just valuable as a ROP trick?<p>But if I have that, isn&#x27;t just writing to the actual stack more valuable? Why does stack growth matter at all besides being a complication where one can not write to one specific page?<p>How does this get you to write to out of process memory?

I&#x27;m very surprised. I was sure -fstack-check was on by default. The fact that it isn&#x27;t secure without it is known for years. Windows compilers have had that check for years. The bug isn&#x27;t in any executables, gcc and all other compilers should have -fstack-check on by default, with optional disable. I&#x27;m even more suprised that people who are supposed to know what they are doing don&#x27;t compile with it.

Could someone explain the situation like if I was 5?

Take note of the Grsecurity section. We already have the technology necessary to mitigate or significantly reduce the impact of these vulnerabilities.<p>Solid writeup.

It&#x27;s not clear to me why compiling all userland code with -fstack-check would help. Couldn&#x27;t you work around that by copying or creating an executable in assembly that doesn&#x27;t write every 4 KB?

On 32bit x86, couldn&#x27;t the SS segment selector be mapped to a completely different set of memory compared to CS&#x2F;DS&#x2F;ES and thus remove the possibiliy of the stack and the heap clashing?

A classic always worth reading: <a href="http:&#x2F;&#x2F;insecure.org&#x2F;stf&#x2F;smashstack.html" rel="nofollow">http:&#x2F;&#x2F;insecure.org&#x2F;stf&#x2F;smashstack.html</a>