# CVE-2023-20963: Android: mismatching parcel/unparcel logic for WorkSource
*Jann Horn*

## The Basics

**Disclosure or Patch Date:** March 1, 2023

**Product:** Android

**Advisory:** https://source.android.com/docs/security/bulletin/2023-03-01#framework

**Affected Versions:**

**First Patched Version:** Security Patch Level 2023-03-01

**Issue/Bug Report:**

**Patch CL:** https://android.googlesource.com/platform/frameworks/base/+/266b3bddcf14d448c0972db64b42950f76c759e3%5E%21/

**Bug-Introducing CL:**

**Reporter(s):**
 - Android credits Sergey Toshin (@\_bagipro) of Oversecured Inc.
 - public analysis is done in writeups:
   - [by davinci1012/davincifans101](https://github.com/davincifans101/pinduoduo_backdoor_detailed_report/blob/main/report_en.pdf) (in english, chinese version also available)
   - [by Dark Navy](https://mp.weixin.qq.com/s/P_EYQxOEupqdU0BJMRqWsw) (in chinese)

## The Code

**Proof-of-concept:**

**Exploit sample:**

**Did you have access to the exploit sample when doing the analysis?**
haven't looked at it but I guess it's probably public somewhere

## The Vulnerability

**Bug class:** injection via inconsistent parcel serialization/deserialization

**Vulnerability details:**

For background on the bug class, see this bug writeup linked in the
davinci1012 analysis, written in 2017:
https://github.com/michalbednarski/IntentsLab/issues/2#issuecomment-344365482

The commit message of the patch linked above describes the issue pretty well.

**Patch analysis:**

The patch spot-fixes the bug instance in WorkSource so that the treatment of
empty lists becomes the same for serialization and deserialization.

**Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:**

Probably variant analysis specifically looking for inconsistent parcel
serialization and deserialization - maybe manually, maybe by static analysis or
fuzzing.

**(Historical/present/future) context of bug:**

Android's Parcel serialization is a highly fragile mechanism where every object
type that can be serialized has custom code for serialization/deserialization
(typically written in Java), and if there is a mismatch between these, that's
usually a security bug.
Other serialization schemes that rely on code generation from schema definitions
or type-value-length encoding are much less susceptible to such issues.

The davinci1012/davincifans101 writeup says that the malicious app that abused
the bug was also using other issues of the same bug class:

> Among them, SonaAbility is the core of the whole system, which is packed with several 0day and 1day
> Bundle Mismatch vulnerabilities of various platforms for privilege escalation.
> [...]
> This type of vulnerability is favored by PDDs because of the low threshold for stability of exploitation and
> ease of engineering.

## The Exploit

(The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).)

**Exploit strategy (or strategies):** 

**Exploit flow:** 

**Known cases of the same exploit flow:**

**Part of an exploit chain?**

## The Next Steps

### Variant analysis

**Areas/approach for variant analysis (and why):**

Possible approaches to find variants would be:

 - use static analysis to find `Parcelable` types with nontrivial
   serialization/deserialization, then manually look at all of them
 - enumerate all the `Parcelable` types, then use fuzzing to find serialized
   inputs for which a `deparcel -> parcel -> deparcel` round trip results in an
   overrun/underrun in the last deparcel step

**Found variants:**

Only poked around manually a bit so far and found nothing.

### Structural improvements

What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.?

**Ideas to kill the bug class:**

The documentation at
<https://developer.android.com/guide/components/activities/parcelables-and-bundles>
implies that the parcel wire format is not guaranteed to be stable:

> Note: Parcel is not a general-purpose serialization mechanism, and you should
> never store any Parcel data on disk or send it over the network.

This means it should be possible to change the parcel wire format and either
turn it into a proper [TLV format](https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93value)
or at least add length information for each sub-object.
Given that this seems to be a repeating bug class, I think this would be a
relatively low-impact change that could mitigate the bug class.

Android 13
[already mitigates](https://android.googlesource.com/platform/frameworks/base/+/9ca6a5e21a1987fd3800a899c1384b22d23b6dee%5E%21/)
the main method for exploiting this type of bug by isolating the unparcelization
of bundle payloads.


**Ideas to mitigate the exploit flow:**

**Other potential improvements:**

### 0-day detection methods

What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**?

## Other References

 - https://arstechnica.com/information-technology/2023/03/android-app-from-china-executed-0-day-exploit-on-millions-of-devices/
   for more context on the malicious app in which the exploit was found