Re: Qualys Security Advisory - The Stack Clash

[Daniel Micay <danielmicay () gmail com>]

> Ditto for the "move mmap_area and PIE binaries away from the stack"
> patch series posted to LKML and CC'ed to kernel-hardening on June 2:
>
> http://www.openwall.com/lists/kernel-hardening/2017/06/02/

That's tied to this, and talking to Riel about it on IRC, since he's
interested in upstreaming these kinds of changes:

https://gist.github.com/thestinger/b43b460cfccfade51b5a2220a0550c35

He submitted an initial set of the changes moving towards being able to
tie the stack mapping entropy to the mmap_rnd_bits sysctl upstream, and
likely increasing the default value to match the current stack entropy
on 32-bit. It wasn't motivated by stack exhaustion bugs. The stack
rlimit calculation bug and ASLR range overlap issue are something that
has been publicly discussed not tied to this context.

RAND_THREADSTACK wasn't in the scope of that effort because CopperheadOS
does ASLR for secondary stacks in userspace where it can randomize lower
bits along with splitting a region for libraries (incl. dlopen) from the
rest of the mmap usage.

I didn't get early disclosure access or a leak of this round of issues.
I wouldn't have done anything in response to it. I already went through
the userspace Android Open Source Project alloca / VLA uses last year
due to the unavailability of -fstack-check in Clang and only found CVE-
2016-3922 (unbounded VLA at a local privilege boundary), a few bugs that
I considered security bugs but that Google did not and a bunch of bugs
that I ruled out as possible security issues. Some of those are now gone
due to rewrites from C and C style C++ to higher level C++ or Java.

It looks like https://reviews.llvm.org/D34386 is finally going to land
for Rust and then it's straightforward to have Clang stop implementing
-fstack-check as a no-op for architectures where that gets ported. It'll
be nice not needing to carry an out-of-tree patch derived from a failed
past attempt to land it.