New Android Bug Causes “Bricked” Devices

We recently read about an Android system crash vulnerability affecting Google’s Bouncer™ infrastructure, one that, alarmingly, also affects mobile devices with Android OS versions 4.0 and above. We believe that this vulnerability may be used by cybercriminals to do some substantial damage on Android smartphones and tablets, which include “bricking” a device, or rendering it unusable in any way. In this context, the device is “bricked” as it is trapped in an endless reboot loop.

How did they do it?

Our analysis shows that the first crash is caused by the memory corruption in WindowManager, the interface that apps use to control the placement and appearance of windows on a given screen. Large amounts of data were entered into the Activity label, which is the equivalent of the window title in Windows.

If a cybercriminal builds an app containing a hidden Activity with a large label, the user will have no idea whatsoever that this exploit is in fact taking place. Cybercriminals can further conceal the exploit by setting a timed trigger event that stops the current app activity and then opens the hidden Activity. When the timed event is triggered, the exploit runs, and the system server crashes as a result. This stops all functionality of the mobile device, and the system will be forced to reboot.

An even worse case is when the malware is written to start automatically upon device startup. Doing so will trap the device in a rebooting loop, rendering it useless. In this case, only a boot loader recovery fix will work, which means that all the information (contacts, photos, files, etc.) stored inside the device will be erased.

Bug found to crash a series of services.

Further research on our part revealed that apart from the WindowManager service, PackageManager and ActivityManager are also susceptible to a similar crashing vulnerability. The critical difference here is that the user’s device will crash immediately once the malicious exploit app is installed. Note that the exploit app in this case does not need any special permission.

In AndroidManifest.xml, apps’ label names can be set in the “android:label” attribute of the element, and it can be written with a raw string, not only with the reference of the string resource. Normally, apps with very long raw string labels declared in AndroidManifest.xml cannot be installed, due to the Android Binder’s transaction buffer size limit. But through the ADB (Android Debug Bridge) interface, which is used by many third-party market clients, such apps can be installed–which, inevitably, causes an instant PackageManager service crash.

Figure 1. PackageManager service crash

In a chain reaction, all other processes that depend upon PackageManager crashes and leaves the Android device completely unusable. Below are notifications of some crashed services, which include Launcher and android.process.acore.

Figure 2.Crashed services that depend on PackageManager

The system service ActivityManager is also affected due to the continuous error in the Binder transaction. This may possibly lead to a Binder driver crash, which then results in an automatic rebooting of the device. At this point, users would have no other recourse but to do a hard factory reset on the device while running the risk of erasing all of the stored data.

Figure 3.Binder driver crash (click thumbnail for full view)

What should users do?

As always, we advise users to never download apps from third-party app stores. It’s important to treat third-party apps with a healthy dose of suspicion and skepticism as cybercriminals are always on the lookout to find and exploit every nook and cranny in Android devices. Google has already been notified about the vulnerabilities but users should still take the necessary precautions in order to protect their mobile devices.

We have informed Google’s Android security team about this issue.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

New Android Bug Causes “Bricked” Devices