Cross-Signed Certificates Crashes Android

We have discovered a vulnerability in Android that affects how cross-signed certificates are handled. No current Android release correctly handles these certificates, which are created when two certificates are signed with a looped certificate chain (certificate A signs certificate B; certificate B signs certificate A). We’ve already notified Google about this vulnerability, and there is no fix and no timeframe for a fix from them.

When a specially-constructed malformed certificate is introduced into an Android device (either by a new app being installed or by importing a certificate), the system may behave in unexpected ways. It may either slow down or hang the device until it is forced to reboot.

Vulnerability Description

The vulnerability is caused by two common used classes in the Android framework – the JarFile and KeyStore classes. Any Android features implicitly or explicitly using the either of two classes may be at the risk to be attacked by cross-signed certificates.

Android commonly used class JarUtils (./libcore/luni/src/main/java/org/apache/harmony/security/utils/JarUtils.java) – These may be used by the JarFile class. It is used to verify a jar package’s certificates and signature files. Unfortunately, the JarUtils class cannot properly deal with a loop certificate chain and falls into endless loop. The problem happens in all Android versions.
Android external KeyStore providers’ classes (Such as ./external/bouncycastle/src/main/java/org/bouncycastle/jce/provider/JDKPKCS12KeyStore.java) – These are used to process PKCS#12 file for the Android KeyStore. If the PKCS#12 file contains a loop certificate chain, the processing in the codes will also fall into endless loop.

Proof of Concept

We will demonstrate this vulnerability with two different scenarios. In one scenario, a specially crafted app is installed onto the device. In the other, a specially crafted keychain is imported.

By manipulating the signing process using different certificate signing requests, we can easily generate a pair of cross-signed certificates: A.cert whose issuer is B.cert, and B.cert whose issuer is A.cert.

In scenario #1, we will install a new app signed by one of the above certificates. We create a new app called LoopCertsChain, signed by A.cert, and try to install it onto an Android device. (The screenshots below are on a device with Android 4.1.2, although versions up to 4.4 are affected.) We get the following UI, which never ends.

Figure 1. Attempting to install app

Upon closer examination, we find a key process (system_server) in Android keeps using up system resources until it is killed, which triggers a device reboot. The user has no choice in the matter.

Figure 2. system_server process consuming more resources

In the second scenario, we import a malformed PKCS#12 file with a loop certificate chain into Android.

Figure 3. Keychain being imported

The corresponding Android process com.android.certinstaller also falls into a loop until it is killed.

Figure 4. com.android.certinstaller process consuming more resources

This vulnerability does not have any direct security implications at this time. However, it is possible that future research may reveal that further problems exist in these portions of Android that may have more direct consequences, such as running arbitary code.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Cross-Signed Certificates Crashes Android