Android is an operating system that is present in countless devices around the world, not just smartphones and tablets, but today it is present in TVs, fridges and even cars. This is all possible thanks to its sophisticated architecture, capable of meeting the specific demands and customizations required for each type of device and different manufacturers. And despite its sophistication, it still offers a certain ease for developing applications and implementing additional functionality.
However, no matter how robust and complete an operating system is, it's not impossible for there to be programming errors, security vulnerabilities and even design flaws that can be exploited by malicious agents.
In this blogpost, we'll talk about inter-process communication (IPC)[1], introducing one of the Android features responsible for it, called Parceable, understanding how it works and why it was created. After that, we'll talk about security vulnerabilities that have arisen in this context, how they have been fixed and the new mechanisms introduced in new versions to try to prevent new security flaws.
Process communication in Android
To provide compatibility and allow information to be exchanged between different processes and applications, Android has an inter-process communication (IPC) system. This system is based on serializing data in structures called bundles, which are objects used to send primitive data (bytes, int, char, among others). These "bundles" of bytes are sent to another agent called a Binder[2], which in turn sends them to the target application/process, where they will be deserialized and processed.
However, in some applications and use cases it is necessary to send composite or complex data, such as personalized information specific to a class, and it is in this situation that the use of Parcel is recommended. In this scenario, the custom class must implement Parceable and use the methods defined by it to package and unpack the parcels that will be used.
If the implementation of this serialization-sending-deserialization protocol contains errors, security vulnerabilities can occur. In this way, data sent to Android's most critical applications and/or services can be intentionally corrupted, resulting in the possible leakage of sensitive data or even the installation of malicious applications (malware).
EvilParcel Vulnerability
A vulnerability that demonstrates the malicious behavior described in the previous paragraph occurred in CVE-2017-13315, also known as EvilParcel[3]. To understand how this vulnerability occurred, we must first talk about the flaw it abused:
Compatibility errors were found between the writing (serialization) and reading (deserialization) of packages in the implementations of several classes that used the Parcel[4] framework for inter-process communication.
How data is organized within Parcel:
The flaw found occurred when the target process, after receiving the serialized parcel, performed deserialization incorrectly, precisely because it contained implementation errors in its code, and ended up reading more or fewer bytes of each piece of data, causing a misalignment in the boundaries of the data blocks and messing up the entire parcel structure from that point on. Once the boundaries of each piece of data within the parcel have been modified, it is possible to generate data that didn't exist before or to omit data.
Data organized after incorrect reading:
Note that both reading and writing were performed in a mandatory sequential mode, which forced the target process to unpack the parcel completely before accessing any of the data it contained.
But what could be done about this flaw?
In a communication between three processes, it was possible to add a piece of data in an intentionally calculated position at the source, which would become "hidden" to the intermediate process and only revealed at the destination.
In this way, a malicious program could send an apparently ordinary request to a service with high privileges, pass the validation of this intermediate process and execute actions that it was not previously allowed to do through the privileged service. In the case of EvilParcel, this abuse of validation occurred mainly with the intention of installing other programs or leaking data.
Schematic of how the EvilParcel vulnerability works:
New communication in Parcelable
Android developers have continually improved the mechanism for intercommunication between processes in order to avoid bugs and security vulnerabilities.
In Android 13, the new LazyBundle[5] feature has added more robustness to communication between different processes. With this new feature, the objects to be transmitted continue to be serialized in primitive structures such as parcels, but with support for more complex structures, including abstract classes and objects with interfaces. Thus, even when the structure sent is not of a primitive type, its size is written in Parcel, avoiding compatibility problems between what is read/written.Amid so many improvements, we can say that the most significant change has occurred in the process of reading the parcel, which is no longer sequential and no longer requires the complete deserialization of the package in order to retrieve a single piece of data, a behaviour which gave rise to the name LazyBundle and which has made communication between processes faster and more secure.
LeakValue Vulnerability
The LazyBundle mechanism fixed known vulnerabilities related to Parcel, however, it also introduced the possibility of new vulnerabilities. This was the case with the LeakValue vulnerability (CVE-2022-20452)[6], disclosed in January 2023, which allowed an attacker to execute arbitrary code and gain superuser privileges on the device.
The basic concept of this vulnerability is similar to that of the "use-after-free" vulnerability, which is caused by the incorrect use of a program's dynamic memory. In this vulnerability, due to problems in the implementation, the pointer to a memory that is no longer being used (the memory is said to have been "freed") is kept. This implementation error allows an attacker to use this pointer to break the functioning of the application or even execute arbitrary commands on the system.
The LeakValue vulnerability occurs due to a flaw in the recycling of objects of type parcel, and can therefore be classified as a "use-after-recycle" vulnerability.
By recycling lazy bundles (built using LazyBundle), it is possible to send data to Android system servers[7]. Among the various possible actions that the system servers perform, you can launch the System Settings application, which in turn can execute an arbitrary program controlled by the attacker and grant the attacker superuser privileges.
Conclusion
During the studies on IPC vulnerabilities in Android, it became clear that attackers are always looking for new ways to exploit vulnerabilities and often use existing concepts and techniques, adapting them to current targets and technologies.
Therefore, it is not only necessary to be aware of known vulnerabilities, it is also important to be aware of new vulnerabilities that are constantly disclosed by researchers or the media. It can be said that no system or solution is 100% secure, not even the latest ones or those that receive security updates, and that every solution is a potential target.
Finally, it is important to carry out audits to check that your solution, application or system is sufficiently protected or that it complies with current best security practices. To do this, simply contact SiDi's commercial team and ask for a security assessment.
Authors: Agostinho Sanches de Araujo, Andre Henrique Cunha de Moraes and Sabrina da Silva Miranda
References
[1] Introduction to IPC on Android: https://medium.com/@vardaansh1/an-introduction-to-android-interprocess-communication-and-common-pitfalls-ac4dfeddf89b [2] Android Binder: https://developer.android.com/reference/android/os/Binder [3] Evil Parcel vulnerability: https: //habr.com/en/companies/drweb/articles/457610/
[4] Black Hat presentation: "Android parcels: the bad, the good and the better " https://i.blackhat.com/EU-22/Wednesday-Briefings/EU-22-Ke-Android-Parcels-Introducing-Android-Safer-Parcel.pdf
[5] LazyBundle - Google https://android.googlesource.com/platform/frameworks/base/+/9ca6a5e21a1987fd3800a899c1384b22d23b6dee%5E%21/ [6] LeakValue vulnerability: https://github.com/michalbednarski/LeakValue [7] Android System Server: https: //medium.com/@khetanrajesh/android-boot-up-process-system-server-940f210d0194