Preface

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?

Start discussion

We discuss ASLR topics in our earlier discussion (see below).  Our discussion last time focus on virtual machine (VM) especially VMware.

Copy – He is great partner of virtual machine but he can kill VM simultaneously – address space layout randomization

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?

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

 

Mobile apps like your wife or girlfriend. They are tracing you!

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

a. The drawback is that when code are written in negligence form result that unused objects are referenced somehow from reachable objects, garbage collection would mark unused objects as useful object. As a result it would not be able to remove. This is called a memory leak. From technical point of view, memory leak will be few kilo bytes to mega bytes. However mobile phone application relies on  java engine and Java script. Java dynamic language use garbage collect to management memory. To enhance CPU performance, a caching technology will be in use. A design weakness was found is that component shares some of its cache with untrusted applications. Hacker could send malicious JavaScript that specifically targeted this shared memory space.  A known bug (see below CVE details) confirm that JavaScript Attack Breaks ASLR on CPU Micro-Architectures  (vulnerable CPU displayed as below:)

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
CVE-2017-5928 is assigned to track the JavaScript timer issues in different browsers

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.

Summary:

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!