Date: Wed, 12 Jul 2017 20:03:09 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: stack clash in musl? * Tycho Andersen <tycho@...ker.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).
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ