Address space layout randomization (ASLR) is a computer security technique which popular in cyber world today. Since it reduce the ratio of incident hit rate of malware infection. Do you agree that there is not required to worries about malware infection once ASLR implemented?
We discuss ASLR topics in our earlier discussion (see below). Our discussion last time focus on virtual machine (VM) especially VMware.
We move our focus on mobile phone this time especially Android system. As far as we know, chip-set vendors (Qualcomm and Intel) going to reduce the attack surface with division of duty of design.
Highlight of division of duty of design on mobile chip set
Baseband processor: Manages all the radio functions except Wi-Fi and Bluetooth radios. A baseband processor typically uses its own RAM and firmware.
WiFi chip-sets: responsible for handling the PHY, MAC and MLME on its own, and hands the kernel driver data packets that are ready to be sent up.
Reference point: We noticed that research found that hacker can implant malicious code relies on WiFi chip-set design weakness to compromised Baseband processor. Since WiFi chip-set did not protect by ASLR technique. But this time we are not going to focus on chipset design weakness from mobile phone topic. As such we move on to the following items of discussion.
ASLR implementation status on Android
Early Android versions only had stack randomization due to lack of kernel support for ASLR on ARM. The address space layout randomization (ASLR) has been adopted in their design since 2015. Android version 4.1 introduced support for full ASLR by enabling heap randomization and position Independent Executables (PIE). But we frequently heard that Android OS encountered malware infection. But what is the root causes?
- Non traditional spawning model
On Android system (from my personal view point it is a tailor made Linux), but the memory management design have different. A process so called Zygote.
However the zygote process have design limitation. It might have possibilities let malware to do the infiltration (see below detail for reference).
2. Memory leak
Android system needs to manage memory allocation resources. A programmatically initiate that Garbage initiation when memory runs short. Garbage collection base on the following criteria.
a. Verify all object references in memory , non reachable object will go to Garbage collection. Everything else are wiped out from memory to free up resources
b. Everything serving the user should be kept in memory
Garbage collection design weakness Highlight
CVE – vulnerabilities on CPU
CVE-2017-5925 is assigned to track the developments for Intel processors
CVE-2017-5926 is assigned to track the developments for AMD processors
CVE-2017-5927 is assigned to track the developments for ARM processors
Vulnerable CPU (mobile phone devices)
Allwinner A64 ARM – Cortex A53 (2016)
Intel Xeon E3-1240 v5 – Skylake (2015)
Intel Core i7-6700K – Skylake (2015)
Intel Celeron N2840 – Silvermont (2014)
Samsung Exynos 5800 – ARM Cortex A15 (2014)
Samsung Exynos 5800 – ARM Cortex A7 (2014)
Nvidia Tegra K1 CD580M-A1 – ARM Cortex A15 (2014)
Nvidia Tegra K1 CD570M-A1 – ARM Cortex A15; LPAE (2014)
b. The side-channel attack capable to bypass ASLR algorithm and assists malware implant to the system. The modern CPU require work with internal or external cache. Therefore this is the other alternative way may potentially bypass ASLR memory protection.
i. Evict + time
The attacker measures the time it takes to execute a piece of victim code. Then attacker flushes part of the cache, executes and times the victim code again. The difference in timing tells something about whether the victim uses that part of the cache.
ii. Prime + probe
The attacker now accesses memory to fill part of the cache with his own memory and waits for the victim code to execute. (Prime) Then the attacker measures the time it takes to access the memory that he would carefully placed in cache before. If it’s slow it is because the victim needed the cache and this gives us knowledge about what victim did. (Probe)
iii. Flush + reload
The flush and reload attack utilizes that processes often share memory. By flushing a shared address, then wait for the victim and finally measuring the time it takes to access the address an attacker can tell if the victim placed the address in question in the cache by accessing it.
It looks that new technologies claimed that it avoid malware infection. For instance 64-bit OS and ASLR. As a matter of fact, these technology are valid and required. However we can’t say we are now secure! Refer to above discussion. Any mis-use operation or negligence form of programming technique, hacker might find vulnerability to compromise your mobile system even though ASLR is running on your mobile.
Tips to detect Android memory leak
LeakCanary is an Open Source Java library to detect memory leaks in your debug builds.
You create a RefWatcher instance and give it an object to watch:
// We expect java-id-session to be gone soon (or not), let's watch it. refWatcher.watch(java-id-session);
When the leak is detected, you automatically get a nice leak trace:
* GC ROOT static .............. * references ............. * leaks ....... instance
Have a nice weekend!