stack clash in musl?

stack clash in musl?

[Tycho Andersen]

Hi all,

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?

Cheers,

Tycho

Re: stack clash in musl?

[Szabolcs Nagy]

* 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).

Re: stack clash in musl?

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2017-07-12 20:03:09 +0200]:
> * 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:
> 

stack adjustments in more detail (aarch64 libc.so):

> BF_crypt.part.0
sp -= 4336

> __dls2
early startup
sp -= 8 * symbolic relocs in libc (= 39 now) < 400

> __dls3
early startup
CRTJMP sets initial sp

> __execvpe
sp -= x
x <= PATH_MAX + NAME_MAX + 1 = 4352

> __netlink_enumerate
sp -= 8256
(called from if_nameindex, getifaddrs)

> _longjmp
restores sp to a previous value.

> dcngettext
sp -= x
x = dirlen+1 + loclen+modlen+1 + catlen+1 + domlen+3 + 1 < 4392 (i think)
(could be truncated to PATH_MAX before stack allocation)

> decfloat
sp -= 8368
(float scanf/strtod)

> execl
> execle
> execlp
depends on argument list length in source code,
not exploitable (there won't be any call to these
functions with >100 args in a setuid binary)

> fmt_fp
sp -= 7616
(float printf)

> getcwd
sp -= 4112

> load_library
sp -= x
x <= PATH_MAX + ldso_path_len < 4150
(only at first library load at early startup or dlopen)

> match_in_dir
sp -= x
x <= PATH_MAX+1 = 4096
(called from glob)

> nftw
sp -= 4160

> realpath
sp -= 4432

> tempnam
sp -= 4288

early start up code, longjmp and execl are unlikely to be exploitable
which leaves (in size order):

strtod,float *scanf: 8368 (unlikely in setuid)
if_nameindex,getifaddrs: 8256 (rare network apis)
float *printf: 7616 (unlikely in setuid)
realpath: 4432
dcngettext: <=4392
execvp,execlp,posix_spawnp: <=4352
crypt: 4336
tempnam: 4288
nftw: 4160
dlopen: <4150
getcwd: 4112