This looks pretty brutal.<p>Quote from Kurt Seifried of RedHat <a href="http://www.openwall.com/lists/oss-security/2017/06/19/2" rel="nofollow">http://www.openwall.com/lists/oss-security/2017/06/19/2</a><p>"<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>"<p>Debian security advisories rapid fire:<p>glibc <a href="https://lists.debian.org/debian-security-announce/2017/msg00146.html" rel="nofollow">https://lists.debian.org/debian-security-announce/2017/msg00...</a><p>linux <a href="https://lists.debian.org/debian-security-announce/2017/msg00148.html" rel="nofollow">https://lists.debian.org/debian-security-announce/2017/msg00...</a><p>exim4 <a href="https://lists.debian.org/debian-security-announce/2017/msg00147.html" rel="nofollow">https://lists.debian.org/debian-security-announce/2017/msg00...</a><p>libffi <a href="https://lists.debian.org/debian-security-announce/2017/msg00149.html" rel="nofollow">https://lists.debian.org/debian-security-announce/2017/msg00...</a><p>And just a sample from the Qualys announcement (out of many more), "local-root exploit against Exim", "local-root exploit against Sudo (Debian, Ubuntu, CentOS)", "local-root exploit against /bin/su", "local-root exploit against ld.so and most SUID-root binaries (Debian, Ubuntu, Fedora, CentOS)", "local-root exploit against /usr/bin/rsh (Solaris 11)", 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't bode well for more vulnerabilities of this nature that don't require local root.
I'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'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'm very surprised. I was sure -fstack-check was on by default. The fact that it isn't secure without it is known for years. Windows compilers have had that check for years. The bug isn't in any executables, gcc and all other compilers should have -fstack-check on by default, with optional disable. I'm even more suprised that people who are supposed to know what they are doing don't compile with it.
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's not clear to me why compiling all userland code with -fstack-check would help. Couldn't you work around that by copying or creating an executable in assembly that doesn't write every 4 KB?
On 32bit x86, couldn't the SS segment selector be mapped to a completely different set of memory compared to CS/DS/ES and thus remove the possibiliy of the stack and the heap clashing?