Android bug that crashed Google Play can brick devices too

Android bug that crashed Google Play can brick devices too

Summary: Attackers could use a recently-revealed flaw to disable their target's device and destroy their data.

TOPICS: Android, Security

Cybercriminals might be more interested in stealing a victim's data than bricking their smartphone, but a newly-discovered bug in Android could potentially allow them to do just that.

The flaw, which affects Android 4.0 and upwards, was reported by London-based researcher Ibrahim Balic on earlier this month as a memory corruption bug, which allows a malformed APK file to force Android OS to crash.

According to Balic, the bug can be triggered by setting the application name parameter ('appname') to greater than 387,000 characters. Besides crashing Android devices, shortly after Balic uploaded his proof of concept exploit file to Google Play to test it against Google's Bouncer, hundreds of developers reported being unable to upload their apps to Google's marketplace for several hours, suggesting to Balic that it also caused a denial of service there.

A further analysis released yesterday by Trend Micro highlights that Balic's exploit can cause several Android device services to crash, including WindowsManager, PackageManager and ActivityManager, making it a potentially valuable tool for cybercriminals.

"We believe that this vulnerability may be used by cybercriminals to do some substantial damage on Android smartphones and tablets. The device is stuck in an endless reboot loop, or a bootloop. This can render the device unusable, which some may consider 'bricking' it," Trend Micro's mobile threat analyst Veo Zhang said.

According to Zhang, Balic's exploit involved entering large amounts of data into the Activity label, which is the equivalent of the window tile in Windows. 

The avenue that Balic used to insert an oversized name was AndroidManifest.xml, an Android element which allows developers to, for example, change an existing app's name without creating an entirely new project.

According to Zhang, it wouldn't be possible to set an app name to a string as large as Balic had done were it not for a commonly used tool known as Android Debug Bridge.

"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."

As far as the potential for cybercriminals to exploit the vulnerability goes, Zhang points out that they could build an app containing a hidden Activity with a large label that exploits and crashes the devices when it is running. In this case, it will cause the device to crash and reboot.

The worst case scenario, however, 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," Zhang said.

ZDNet has asked Google for comment and will update the story if it receives one. 

According to Trend Micro, Google has been notified of the vulnerability. 

Read more on Android security

Topics: Android, Security

Liam Tung

About Liam Tung

Liam Tung is an Australian business technology journalist living a few too many Swedish miles north of Stockholm for his liking. He gained a bachelors degree in economics and arts (cultural studies) at Sydney's Macquarie University, but hacked (without Norse or malicious code for that matter) his way into a career as an enterprise tech, security and telecommunications journalist with ZDNet Australia. These days Liam is a full time freelance technology journalist who writes for several publications.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • a typical non issue for mainstream users

    "But through the ADB (Android Debug Bridge) interface, which is used by many third-party market clients..."

    This is typical. Most mainstream users and readers of this do not use 3rd party market clients, nor ADB debug interface to load apps. As usual, its the required avenue of malware infection that makes it practically a non issue. Security requires multi layers of protection.

    Note I also just defended windows XP in another post claiming that you just needed to send a text message to an ATM to despense cash. There was a slight caveat: you needed a physical connection to the ATM.
    • ADB access

      With ADB access, we can root the device and basically do whatever we want, what's the point in injecting an APK to bootloop it?
      This is a pointless vulnerability.
  • Missed a paragraph

    The issue here is that the bad Activity label can be embedded IN an app. The app itself may go up just fine. The ADB thing was just to show what would happen and crash Google Play. For the rest of us, the issue is that within an app that ordinarily is just fine, a hidden Activity could be present that when invoked, could cause the corruption and the crash. Then if that dropped malware that runs on restart, it could continue the process infinitely, until the device was wiped clean. That is the bug for the rest of us. The ADB thing is just a problem for Google, except for it illustrates something else to look at when vetting an app, or something that needs to be fixed internally to Android so this kind of thing can't happen.

    Now the XP thing is pretty funny. If I could get physical access to an ATM so I could hook up something so I could get a text into it, then why not just empty the cash drawer and go home. Oh well, why make something easy when you could make it hard...
  • Lets get this right

    We need ADB to install the APK to ex ploit this vulnerability.
    You need physical access to the device to ADB sideload the APK.
    You also need to have developer options overide enabled to have the USB debug mode enabled.
    That's quite a few doors that need to be opened in order for this exploit to have a chance.
    Normal sideloading won't allow the corrupt APK to install.
    I think you have bigger problems if the hackers have physical access to your phone.