[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170712180308.GE10974@port70.net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
