Android Serialization Vulnerability--cve-2015-3525

In 2014, Jann Horn found an Android right to exploit the vulnerability, which allowed malicious applications to power from normal app permissions to system user execution commands, vulnerability information and POC see (1]. The vulnerability stems from the fact that in the Android system (<5.0), Java.io.ObjectInputStream does not verify that the input Java objects are actually serializable. An attacker could therefore build an instance of a non-serializable Java object, maliciously construct its member variable, and when the object instance was ObjectInputStream deserialized, type confusion would occur, and the object's field would be treated as a pointer to the local code, giving the attacker control. This is cve-2014-7911. Before we get into the details of it, let's start by understanding the following basics:

Android IPC mechanism

Use sandbox isolation between Android apps to protect security. However, they can interact with each other through the intent messaging mechanism. The delivery of complex data types at interaction must be serialized by the sender, and then deserialized by the receiver. For the convenience of developers, Java provides built-in support for serialization.

Java serialization

The purpose of serialization serializable is to store the data object in a byte stream and regenerate the object when needed. There are two ways to serialize objects in intent in Android, one is bundle.putserializable (Key,object) and the other is Bundle.putparcelable (Key, Object). The former is the implementation of the serializable interface, while the latter is the implementation of the Parcelable interface. Serializable is stored on the hard disk using IO Read and write, while the parcelable is read and written directly in memory, it is clear that the memory reads and writes more often than IO reads and writes, so parcelable is preferred in Android. However, parcelable cannot use the case where data is stored on disk, because Parcelable does not guarantee the continuity of the data in the event of a change in the outside world. So in this case the serializable is used.

The function of the implements serializable interface is to give the object a marker and the system will automatically serialize it.

For example, serialized (and other) objects can be added to intent's extras in the following form:

1 serializabletypeobj = ... 2 3 Bundle b = Intent.getextras (); 4 5 b.putstring ("foo", "some string"); 6 7 b.putserializable ("bar", obj);

The code to receive the data is as follows:

1 Bundle b = Intent.getextras (); 2 3 string foo = (string) b.getstring ("foo"); 4 5 serializabletypeobj = (serializabletype) b.getserializable ("Bar");

Java garbage collection mechanism (GC)

We mainly introduce the Finalize () method in the Java garbage collection mechanism.

The Finalize () method is a method that all entity objects have, because this is defined by the object class and is often mistaken for garbage collection or is called a destructor, not really. Finalize is called (but not absolutely) before the JVM memory is reclaimed, and even if it is not called, the JVM recycle mechanism can locate what is garbage memory by some of the algorithms described later, so what does it do?

Finalize () is actually to do some special memory recycling operations, if the Java research a little bit more, you will find that there is a JNI mechanism in Java, namely: Java Native Interface, this is a Java local interface call, That is, calling other local language information, Java Virtual machine underlying calls are also implemented, this part of the call may exist in the C, C + + language operations, in C and C + + through the new, malloc, realloc and other keywords created by the object garbage collection mechanism is powerless, Because this is not the scope of its management, and usually these objects may be called by the Java corresponding entity, then the corresponding Java object needs to be discarded (does not mean that the recycling, only the program does not use it) to call the corresponding C, C + + provided by the local interface to release the memory information, Their release also needs to be released through free or delete, so we generally do not abuse finalize (), you may think of another class of special reference object release, such as the number of layers reference too many, Java Virtual machine sometimes do not know whether this line of objects can be recycled, Then, you can rewrite the finalize () yourself and release the handle of the built-in object first, so there is no problem, but generally do not misuse.

Having learned this knowledge, let's say cve-2014-7911 's details, presumably: System_server is a critical system process with system permissions, and any application can send a serializable object to it, although system_ The server does not actively invoke the method of the object, but it is called to its Finalize method when the object is in the system GC. Jann Horn discovers android.os.BinderProxy this class invokes a native pointer in the Finalize method, which can be controlled by the attacker to point to any address, thus having the opportunity to cause code execution in the GC.

But Android.os.BinderProxy is a class that cannot be serialized, so theoretically we cannot control the execution of the target process code that will attack by sending its instance, but since Java.io.InputStream does not check whether the received object is serializable, we can use a special method Constructs a serialized pseudo-android.os.BinderProxy to achieve the purpose. It is worth noting that although Android uses the ASLR mechanism, in order to obtain the correct address, it can be based on the fact that both the System_server and the attacker app-zygote fork from the same process, with the same base address, An attacker can know the System_server and the memory layout of the loaded module by analyzing the map file of his or her own process (located in/proc/maps). Google's patch added a serialization check to Java.io.InputStream to prevent an attacker from sending android.os.BinderProxy, but with this vulnerability we can find a serializable class that can replace Android.os.BinderP if the following conditions are met: Roxy implements the purpose of code execution:

(1) The Finalize method is realized;

(2) A native pointer is called in the Finalize method;

(3) The native pointer is controllable by the attacker (not declared as transient and static);

(4) implements the Serializible interface (serializable);

(5) There is no overloaded readobject and Readresolve methods to prevent us from controlling the native pointer.

IBM Security found a class opensslx509certificate (cve-2015-3525) in the Android native framework, on Google Play Services The Opensslx509certificate class is used in the APK. There are also 6 vulnerable third-party SDKs found:

• Jumio (cve-2015-2000)
• MetaIO (cve-2015-2001)
• Pjsip PJSUA2 (cve-2015-2003)
• GraceNote GNSDK (cve-2015-2004)
• MyScript (cve-2015-2020)
• Esriarcgis (cve-2015-2002)

So are there some similarities in these SDKs? The analysis found that the top 5 used swig, an interoperability tool that connects a variety of high-level languages, such as C + + and Java. In some developer-supplied configurations, Swig can produce the following vulnerability code:

As bar can be serialized, Foo can be serialized, so an attacker can control swigcptr (and Swigcmemown), and swigcptr is used in native code. Thus this is a highly qualified scenario to be exploited, especially when the original C + + class has a virtual destructor.

By analyzing this vulnerability, we can see that the cve-2014-7911 patch only tightens the attack interface without really solving the problem. Google then released the cve-2015-3525 patch, declaring the native pointer in the Opensslx509certificate class as transient so that the pointer could not be serialized. However, even if the native world of Android fixes all the dangerous serializable classes, the presence of such classes in the third-party SDK can still be used for serialization attacks. IBM Security recommends modifying the bundle's parsing internal resources to lazy behavior and modifying read methods such as ReadObject, Readresolve, and so on to prevent attackers from controlling dangerous variables.

Reference article:

Https://github.com/retme7/CVE-2014-7911_poc

http://researchcenter.paloaltonetworks.com/2015/01/ cve-2014-7911-deep-dive-analysis-android-system-service-vulnerability-exploitation/

Http://www.freebuf.com/news/74676.html

Android Serialization Vulnerability--cve-2015-3525