So it turns out vanilla Android really only has ~2-3 bits of ASLR entropy for mmap (secondary stacks, dlopen, malloc). That's really sad.
@CopperheadSec How do you propose 16-20 bits of entropy in a 20-bit page address space without rapid catastrophic fragmentation?
-
-
@RichFelker It only randomizes the base, so it's a fixed cost. The cost of 16-bit entropy would be 256MiB of virtual memory with 4096 pages. -
@RichFelker Can then do a bit better (but it's hard to quantify) with fine-grained randomization within malloc, for secondary stacks, etc. -
@RichFelker I'd expect something like 16-bit on 32-bit and 17-bit for 32-bit processes with a 64-bit kernel. -
@RichFelker Saying "16-20" was silly since 20 is the whole address space for a 32-bit processes running on 64-bit. :P -
@RichFelker AFAIK, OpenBSD is the only OS doing fine-grained randomization for mmap beyond just the base address. -
@CopperheadSec Userspace could emulate that just by mmap PROT_NONE with random size before each mmap, then munmapping it. -
@RichFelker That's essentially what CopperheadOS does for stacks but it keeps it around until unmapping: https://android-review.googlesource.com/#/c/161453/ -
@RichFelker An attacker can overcome stuff like this via influence over heap allocations if reuse of the random gaps is allowed. - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.