Increasing the range of address-space layout randomization [LWN.net]

Increasing the range of address-space layout randomization

Posted Dec 17, 2015 12:29 UTC (Thu) by wodny (subscriber, #73045)
Parent article: Increasing the range of address-space layout randomization

It's worth mentioning that situation on Android is even worse than on a regular Linux. Take a look at articles titled "From Zygote to Morula: Fortifying Weakened ASLR on Android"[1] and "One Class to Rule Them All: New Android Serialization Vulnerability Gives Underprivileged Apps Super Status"[2] -- "Our PoC exploit uses the fact that all apps and some services, including our malicious process, are forked from the Zygote process. Since all of its forked processes inherit the same memory layout, it makes the address space layout randomization (ASLR) effectively useless". So one vulnerable or malware app allows to map the memory layout and another app can be then exploited using ROPs as it inherits almost the same memory layout.

[1] http://wenke.gtisc.gatech.edu/papers/morula.pdf
[2] https://securityintelligence.com/one-class-to-rule-them-a...

to post comments

Increasing the range of address-space layout randomization

Posted Dec 17, 2015 19:57 UTC (Thu) by thestinger (guest, #91827) [Link] (1 responses)

The Zygote-based process spawning applies to the Java runtime (apps and the system_server), not native processes like mediaserver.

Increasing the range of address-space layout randomization

Posted Dec 17, 2015 23:03 UTC (Thu) by wodny (subscriber, #73045) [Link]

Java runtime + all dynamically linked libraries NDK apps use. So even though you don't gain control over a privileged process like the mediaserver easily, you can still exploit libraries like stagefright (or libchromium_net.so from the Zygote document) to run (almost) arbitrary assembly and try to escalate privileges attacking the kernel or any other component you can interact with.