[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1498063472.27465.6.camel@gmail.com>
Date: Wed, 21 Jun 2017 12:44:32 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Qualys Security Advisory - The Stack Clash
> 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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
