Re: stack clash in musl?

[Szabolcs Nagy <nsz@port70.net>]

* Tycho Andersen <tycho@docker.com> [2017-07-12 08:52:02 -0600]:
> It looks like there were some bugs that affected glibc in the recent
> stack clash wave of issues:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000366
> 
> I guess musl wouldn't be vulnerable to this since it ignores
> LD_LIBRARY_PATH for setuid binaries. I'm curious if anyone else has
> thought about if there are ways to exploit musl using a stack clash?


to jump across a guard page you need >pagesize sp adjustment
without intermediate memory access, in musl very few functions
use >4k stack, this can be easily verified.

e.g. on aarch64 the only instructions that allow sp to be
adjusted by more than 4k are add, sub, mov (+bitwise operations,
but those are not used on sp other than for alignment)

so after a quick grep of aarch64 libc.so disasm here is the list
of functions you should look out for:

BF_crypt.part.0
__dls2
__dls3
__execvpe
__netlink_enumerate
_longjmp
dcngettext
decfloat
execl
execle
execlp
fmt_fp
getcwd
load_library
match_in_dir
nftw
realpath
tempnam

it is guaranteed that no other function can be used for exploit
and even some of these are false positives or barely go above 4k
(which makes exploitation hard), it is also not possible to use
libc functions to grow the stack closer to the heap: only nftw
and regcomp may use more than 10k stack and they have bounded
stack usage too.

tl;dr stack clash does not affect musl (it might affect
application code outside of musl so a musl libc based system
may be still affected).