IBM discovers Android serialization vulnerability allows arbitrary code execution

IBM's x-force application security research team has discovered a security vulnerability in the way that Android handles deserialization and allows for arbitrary code execution and privilege escalation.

In a blog post describing the vulnerability, security researcher Or Peles said that the vulnerability affected more than 55 percent of Android devices -- from Android 4.3 to 5.1, and the first preview of Android's upcoming M release.

Using the vulnerability, an attacker would be able to replace an application running on the target device; exfiltrate data; bypass SELinux by changing the SELinux policy; and, on some devices, execute arbitrary kernel code. In a video demonstration, IBM showed how the Facebook app is able to be replaced by another app.

"The discovered vulnerabilities are a result of the attacker's ability to control pointer values during object deserialization in arbitrary apps' memory space, which is then used by native app code invoked by the runtime's garbage collector," Peles said.

Peles and his team were able find a vulnerable class that was available system-wide in the form of OpenSSLX509Certificate, and then built a proof of concept that was able to execute arbitrary code.

"This game is asymmetric, as one vulnerable class that is available to the default Android class loader is enough for all apps (or one highly-privileged service) to be compromised," Peles and Roee Hay, also from IBM Security, wrote (PDF).

The team found that the vulnerability existed not only in Android and Google Play Services, but also in a number of third-party software development kits, including Jumio, MetaIO, and MyScript, the common thread being use of SWIG.

Defeating the vulnerability was as simple as adding the Java transient keyword to class properties to ensure that they were not serialized.

Peles said that Google has fixed the issue in Android 4.4, 5.0, 5.1, and M, and third-party SDKs had remedied the vulnerability either by adding the transient modifier, reworking their code to drop SWIG, or overriding methods using the serialization process.

"Since the generated vulnerable code was due to bad configuration given by the developer, we do not consider SWIG to be vulnerable," Peles said. "This is somewhat analogous to blaming a compiler for buffer overflows. However, even the most competent developers could miss the fact that they accidentally extended a serializable class."

In recent weeks, Android has suffered from a number of security issues, including Stagefright and Certi-Gate.

Check Point, the discoverer of the Certi-Gate hole that exploits remote support apps often pre-installed on Android to gain complete control of a device, said yesterday that it had seen Certi-Gate being used in the wild.

Google, along with Samsung and LG, last week committed to delivering monthly patches for Android.

"With the recent security issues, we have been rethinking the approach to getting security updates to our devices in a more timely manner," Dong Jin Koh, Samsung's head of mobile research and development, said at the time.

"Since software is constantly exploited in new ways, developing a fast response process to deliver security patches to our devices is critical to keep them protected. We believe that this new process will vastly improve the security of our devices and will aim to provide the best mobile experience possible for our users."