CVE-2021-0928, incompatibilité de sérialisation writeToParcel/createFromParcel dans android.hardware.camera2.params.OutputConfiguration

Il s'agit d'un exploit utilisant cette vulnérabilité pour une élévation de privilèges depuis une application Android installée vers l'application Paramètres Android (ou toute autre application installée à laquelle l'application pourrait envoyer un <receiver> déclaré dans AndroidManifest.xml ; l'élévation de privilèges en envoyant vers un <activity> était également possible, bien que non présentée ici)

J'ai découvert ce problème à l'origine sur Android 12 Developer Preview 3

La version de l'exploit présente dans ce dépôt fonctionne sur Android 12 Beta 2 et 3

La vulnérabilité a été corrigée dans la première version officielle d'Android 12

Le writeup ci-dessous a été rédigé à l'origine pour Google afin que ce rapport soit considéré comme une chaîne d'exploitation complète

Au moment de la rédaction, Android 12 n'était pas disponible dans l'AOSP (les versions Android Developer Preview/Beta ne sont pas open source)

Introduction à Parcel

La plupart des IPC sur Android sont effectués via la classe Parcel

L'utilisation de base de Parcel est la suivante :```java Parcel p = Parcel.obtain(); p.writeInt(1); p.writeString("Hello");

Ensuite, `Parcel` est envoyé à un autre processus [via `Binder`](https://developer.android.com/reference/android/os/IBinder#transact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)). Alternativement, pour les tests, on peut appeler [`p.setDataPosition(0)`](https://developer.android.com/reference/android/os/Parcel#setDataPosition(int)) pour rembobiner le parcel à sa position initiale et commencer la lecture :```java
int a = p.readInt(); // a = 1
String b = p.readString(); // b = "Hello"

Il convient de noter que Parcel conserve en interne la position à partir de laquelle les lectures sont effectuées. Il est de la responsabilité de l'utilisateur de la classe Parcel de s'assurer que les méthodes read* correspondent aux méthodes write* utilisées précédemment, sinon les lectures suivantes seront effectuées à partir de positions incorrectes dans le tampon.

Parcel offre également la possibilité d'écrire des objets personnalisés, la méthode privilégiée pour ce faire est d'implémenter l'interface Parcelable

Voici un exemple d'implémentation de l'interface Parcelable (code non pertinent supprimé, la classe WindowContainerTransaction est utilisée dans l'exploit dans le cadre de la chaîne de gadgets, mais il n'y a rien de mal à cela)```java package android.window; public final class WindowContainerTransaction implements Parcelable { private final ArrayMap<IBinder, Change> mChanges = new ArrayMap<>(); private final ArrayList mHierarchyOps = new ArrayList<>();

private WindowContainerTransaction(Parcel in) {
    in.readMap(mChanges, null /* loader */);
    in.readList(mHierarchyOps, null /* loader */);
}

@Override
public void writeToParcel(@NonNull Parcel dest, int flags) {
    dest.writeMap(mChanges);
    dest.writeList(mHierarchyOps);
}

@NonNull
public static final Creator<WindowContainerTransaction> CREATOR =
        new Creator<WindowContainerTransaction>() {
            @Override
            public WindowContainerTransaction createFromParcel(Parcel in) {
                return new WindowContainerTransaction(in);
            }
        };

}

Comme on peut le voir ci-dessus, la méthode `writeToParcel()` est utilisée lors de l'écriture. Ensuite, lors de la lecture, la méthode de fabrique `CREATOR.createFromParcel()` est appelée. Il est de la responsabilité de l'implémentation de `Parcelable` de garantir que `createFromParcel` lit la même quantité de données que celle écrite par `writeToParcel`, sinon toutes les lectures ultérieures de ce `Parcel` liront des données à partir d'un décalage incorrect.

Une telle classe peut être écrite dans/lue depuis un `Parcel` via :

* Appel direct de `obj.writeToParcel(parcel, 0)` / `obj = WindowContainerTransaction.CREATOR.createFromParcel()`, ce qui est souvent utilisé lorsque le type de la classe est connu, par exemple lorsqu'un `Parcelable` possède un champ avec un autre `Parcelable` ou dans le code généré par AIDL lorsqu'une méthode RPC définie a un `Parcelable` comme argument
* Via `Parcel.writeParcelable`/`readParcelable`. [`writeParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=1909;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) écrit d'abord le nom de la classe puis appelle la méthode `writeToParcel` de l'interface `Parcelable`. [`readParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=3282;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) lit le nom de classe écrit, trouve la classe portant ce nom dans le `ClassLoader` fourni ou dans `BOOTCLASSPATH` si null a été fourni. Une fois la classe trouvée, son champ statique `CREATOR` est utilisé pour obtenir une instance de [`Parcelable.Creator`](https://developer.android.com/reference/android/os/Parcelable.Creator), qui est la fabrique utilisée pour lire cette classe. Il est important de noter que lorsque la méthode `readParcelable` est utilisée, elle peut lire n'importe quel `Parcelable` disponible dans le classpath, car le nom de l'objet à créer est lu depuis le même `Parcel`
* `readParcelable` est utilisé par de nombreuses autres méthodes de `Parcel`, par exemple `readList` vu dans l'exemple ci-dessus lit les éléments via `readValue`, qui est la méthode la plus générique pour transférer des objets dans un `Parcel`, et l'une des façons qu'elle utilise passe par `readParcelable`. De plus, dans l'exemple ci-dessus, en raison de l'effacement de type de Java, le champ `ArrayList<HierarchyOp> mHierarchyOps` peut en réalité contenir n'importe quels objets pris en charge par Parcel, pas seulement ceux compatibles avec le type spécifié dans la déclaration du type générique

# Incohérences `writeToParcel`/`createFromParcel`

Comme indiqué ci-dessus, il est de la responsabilité de l'implémentation de l'interface `Parcelable` de garantir que `createFromParcel` lit la même quantité de données depuis le `Parcel` que celle écrite précédemment par le `writeToParcel` correspondant. Chaque fois qu'il existe dans `BOOTCLASSPATH` un `Parcelable` pouvant violer ce contrat, cela crée une vulnérabilité car cela permet le scénario suivant :