Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1498111252.32057.3.camel@gmail.com>
Date: Thu, 22 Jun 2017 02:00:52 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com, Qualys Security Advisory
 <qsa@...lys.com>
Subject: Re: Qualys Security Advisory - The Stack Clash

Is it planned to have glibc use a larger 1M gap for secondary stacks
rather than a single guard page? That would be a *lot* easier than it
was to set it up for the main thread stack. It follows the main thread
stack rlimit as a guideline so it seems to make sense to use the same
guard region size too. If it ends up exposed as a sysctl, it could read
the current value from there.

For the local setuid/setgid/setcap binary attack surface, the main
thread stack is most relevant, but in general many cases of large stack
frames that were found are called in threads other than the initial one.
Secondary stacks are also mixed in with other mmap allocations rather
than having a separate ASLR base and glibc doesn't do any secondary
stack ASLR. IIRC, it does cache color the stacks but not randomly and I
don't remember how much space it currently reserves for that.

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.