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):

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.)

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 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 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