if (mOwner) {
    // If the size is going to zero, just release the owner's data.
    if (desired == 0) {
        freeData();
        return NO_ERROR;
    }

    // If there is a different owner, we need to take
    // posession.
    uint8_t* data = (uint8_t*)malloc(desired);
    // SNIP: Check if malloc succeeded
    binder_size_t* objects = nullptr;

    if (kernelFields && objectsSize) {
        objects = (binder_size_t*)calloc(objectsSize, sizeof(binder_size_t));
        // SNIP: Check if calloc succeeded

        // Little hack to only acquire references on objects
        // we will be keeping.
        size_t oldObjectsSize = kernelFields->mObjectsSize;
        kernelFields->mObjectsSize = objectsSize;
        acquireObjects();
        kernelFields->mObjectsSize = oldObjectsSize;
    }
    // SNIP: rpcFields handling for non-/dev/binder Parcels

    if (mData) {
        memcpy(data, mData, mDataSize < desired ? mDataSize : desired);
    }
    if (objects && kernelFields && kernelFields->mObjects) {
        memcpy(objects, kernelFields->mObjects, objectsSize * sizeof(binder_size_t));
    }
    // ALOGI("Freeing data ref of %p (pid=%d)", this, getpid());
    if (kernelFields) {
        // TODO(b/239222407): This seems wrong. We should only free FDs when
        // they are in a truncated section of the parcel.
        closeFileDescriptors();
    }
    mOwner(mData, mDataSize, kernelFields ? kernelFields->mObjects : nullptr,
           kernelFields ? kernelFields->mObjectsSize : 0);
    mOwner = nullptr;

    // SNIP: Allocation count tracking
    // SNIP: Assign data and objects to this object
} else if (mData) {
    // SNIP: Resize data owned by this instance of Parcel
} else {
    // SNIP: Allocate initial data for currently empty Parcel
}

return NO_ERROR;

[Когда был добавлен тот комментарий](https://android.googlesource.com/platform/frameworks/native/+/53b6ffe5af3951e8784c451ef8c4ff19f3d6b196%5E!/), вызов `closeFileDescriptors()` был перенесён из `IPCThreadState::freeBuffer()` (который вызывается в приведённом выше коде через указатель на функцию `mOwner()`) в метод `continueWrite()`, однако логика осталась прежней. В конце концов, `Parcel` — ключевая часть Android IPC, и если бы основной IPC закрывал файловые дескрипторы, которые не должен был, это была бы очевидная проблема.

Это подводит нас к важному моменту: когда используется приведённый выше код? Он используется, когда класс `Parcel` принимает владение данными, полученными от Binder-драйвера (которые в этот момент находятся в [`/dev/binder` `mmap`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/ProcessState.cpp;l=587-592;drc=187efe18e3de6258af0230198c881915cc695567) и не могут быть записаны (любые попытки записи в эту память приведут к `SIGSEGV`)), то есть когда `Parcel` является либо входящими данными транзакции (аргумент `data`, передаваемый в [`onTransact()`](https://developer.android.com/reference/android/os/Binder#onTransact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)), либо входящим ответом (то есть объектом `Parcel`, который был передан в вызов [`transact()`](https://developer.android.com/reference/android/os/IBinder#transact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)) как аргумент `reply`; `transact()` устанавливает ссылку внутри этого объекта `Parcel`).

На практике единственный случай, когда мы попадаем в блок `if (mOwner)`, — это когда система [вызывает `setDataSize(0)` для освобождения данных транзакции](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/IPCThreadState.cpp;l=1483-1488;drc=187efe18e3de6258af0230198c881915cc695567), но в этом случае мы также попадаем в `if (desired == 0)`, который выполняет ранний возврат. Однако при легитимном использовании системы нет сценария, при котором мы бы попали в ветку "If there is a different owner, we need to take possession".

# Запуск пути «take possession»

В одном из моих предыдущих эксплойтов я показал [случай, когда `createFromParcel()` может вызвать `writeInt(0)` для `Parcel`, из которого должен читать](https://github.com/michalbednarski/TheLastBundleMismatch#side-effects). Хотя исправление там предотвратило выполнение любых методов `createFromParcel()`, не относящихся к `Intent`, внутри `AccountManagerService`, путь от `createFromParcel()` к `writeInt(0)` остался нетронутым.

Если вкратце, [внутри `PackageParser` есть следующий код](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/PackageParser.java;l=7789-7795;drc=7d3ffbae618e9e728644a96647ed709bf39ae759):```java
final Class<T> cls = (Class<T>) Class.forName(componentName);
final Constructor<T> cons = cls.getConstructor(Parcel.class);

intentsList = new ArrayList<>(N);
for (int i = 0; i < N; ++i) {
    intentsList.add(cons.newInstance(in));
}

Поэтому, чтобы запустить путь «take possession», нам нужен произвольный вызов `readParcelable` для `Parcel`, который был передан в `onTransact()` в качестве `data`; в этом эксплойте я использую для этого [тот же путь, что использовал ранее в другом](https://github.com/michalbednarski/LeakValue#putting-parcelables-in-system_server-and-retrieving-them). Я добиваюсь того, чтобы `readParcelable` вызывал `PackageParser$Activity.CREATOR.createFromParcel()`, который, в свою очередь, читает имя `PooledStringWriter` и вызывает его конструктор; после этого данные `Parcel` заканчиваются, поэтому `writeInt()` должен перераспределить Parcel, попадая в наш путь «take possession».

Здесь стоит отметить: если бы в этот момент данные `Parcel` не заканчивались, `writeInt()` попытался бы перезаписать данные на месте, что в случае данных, поддерживаемых `mmap` из `/dev/binder`, привело бы к `SIGSEGV`.

# File Descriptor Sanitizer

Моя первоначальная идея заключалась в том, чтобы путь «take possession» закрывал файловые дескрипторы, после чего в конце транзакции эти же дескрипторы были бы закрыты снова; но между этими событиями я мог бы поместить другой файловый дескриптор в `system_server` в рамках другой транзакции и позже получить свой файловый дескриптор обратно, поскольку к тому моменту этот FD ссылается на другой файл.

Это сработало в моём эмуляторе со старой версией AOSP, однако, когда я попробовал более новую версию, этот план был остановлен [File Descriptor Sanitizer (FDSan)](https://android.googlesource.com/platform/bionic/+/refs/heads/main/docs/fdsan.md).

В частности, [в `android-14.0.0_r29` покрытие FDSan было расширено на FD внутри `Parcel`](https://android.googlesource.com/platform/frameworks/native/+/7772039cc5084247450f6113d9a18eca17f672aa%5E!/).

На самом деле, после того как FDSan начал покрывать Parcel, я даже не мог добраться до вызова `closeFileDescriptors()`, когда `Parcel` содержал FD. Перед этим вызовом выполняется вызов `acquireObjects();`, который получает ссылки на хэндлы `Binder` (которые освобождаются вызовом `mOwner()` позже внутри этой функции); однако `acquireObjects()` также [устанавливает теги FDSan для FD](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/Parcel.cpp;l=175-178;drc=f4c9b48c19f1b040efb35932b322f47e7779cafe):```cpp
case BINDER_TYPE_FD:
    if (obj.cookie != 0) { // owned
        FdTag(obj.handle, nullptr, who);
    }

Итак, повторный `FdTag` (без закрытия или смены тега при указании ожидаемого старого тега) приводит к ошибке FDSan, которая прерывает процесс, и мы даже ещё не дошли до вызова `closeFileDescriptors()`. Поскольку путь «вступления во владение» при обычном использовании является мёртвым кодом, такие проблемы могут остаться незамеченными.

Однако мы видим условие `if (obj.cookie != 0)`. Если оно ложно, это означает, что FD, присутствующий внутри `Parcel`, на самом деле не принадлежит этому `Parcel`, и именно пользователь `Parcel` обязан держать их открытыми, пока существует этот `Parcel`. Но поскольку этот `Parcel` только что пришёл из ядра, значения `cookie` на самом деле приходят из исходного процесса и считаются нерелевантными, когда `Parcel` действительно имеет `mOwner`. Однако путь «вступления во владение» на самом деле этого не учитывает и просто копирует значения `cookie`.

Сложив всё это вместе, установив значения `cookie` в ноль на стороне отправителя, мы можем получить `Parcel`, который ссылается на уже закрытые файловые дескрипторы, но при этом не считает себя их владельцем, а значит, не будет закрывать их снова. Это позволяет нам избежать срабатывания FDSan, однако также устраняет любые пути эксплуатации через двойное закрытие.

# Приёмы на стороне Java в Parcel

Такие FD всё ещё могут быть переданы в другой `Parcel` (а затем и в другой процесс), однако наш способ инициировать создание таких висячих FD включает создание `PooledStringWriter` через рефлексию, после чего выбрасывается `ClassCastException`, когда мы пытаемся `add()` его в `ArrayList<IntentInfo>`.

Нам нужно:

* Оказаться в конце `Parcel`, который был передан как аргумент `data` в `onTransact()`
* Выполнить создание `PooledStringWriter`, после чего Parcel будет содержать висячие FD, но также будет выброшено `ClassCastException`
* Дождаться, пока интересующие нас для утечки FD будут выделены внутри `system_server`
* Добиться, чтобы FD из этого `Parcel` были скопированы в какой-то другой `Parcel`, который будет отправлен в наш процесс

Чтобы выполнить все эти требования, мне понадобится использовать как старые, так и новые трюки.

## Старые трюки

Начнём с повторного рассмотрения старых трюков, большинство из них уже описано в моём [`LazyValue`-using-`Parcel`-after-`recycle()` эксплойте](https://github.com/michalbednarski/LeakValue)

1. [Класс `RemoteViews` выполняет десериализацию содержащегося в нём `Bundle` с установленным `Parcel.ReadWriteHelper`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/RemoteViews.java;l=2287-2300;drc=9b2e54f25456f2726ab1a15e6b6dc19395a3b5b4). [Когда установлен `ReadWriteHelper`, `Bundle`-ы десериализуются немедленно, а не лениво](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=1886-1896;drc=e1841f84f41213879e1f1b45ad4300b96970e545). Также стоит отметить, что все `Bundle`-ы, содержащиеся внутри этого `Bundle` в `RemoteViews`, тоже будут десериализованы немедленно, а не только тот, что находится непосредственно внутри `RemoteViews`
2. [Если при десериализации `Bundle` внутри `system_server` выбрасывается `BadParcelableException`, это `BadParcelableException` будет молча перехвачено, а содержимое `Bundle` будет очищено](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=479-485;drc=efb735f4d5a2f04550e33e8aa9485f906018fe4e). Обратите внимание, что наш триггер записи в `createFromParcel` выбрасывает `ClassCastException`, который здесь перехвачен не будет
3. [Класс `ParceledListSlice` во время десериализации выполняет блокирующий исходящий Binder-вызов к объекту, указанному в сериализованных данных](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/BaseParceledListSlice.java;l=95-102;drc=e220b578ebc0885a28b83c95cb9ec78581bd8364), что мы можем использовать, чтобы приостановить выполнение десериализации

Всё это сейчас понадобится, но это ещё не всё.

## Новые трюки

[AIDL — это инструмент для генерации реализации RPC-интерфейса](https://developer.android.com/guide/components/aidl), однако в дополнение к этому он также умеет генерировать реализации структур `Parcelable`.

Эти структуры имеют префикс длины, поэтому разные версии одной и той же структуры совместимы в пределах системы, если только в середину не добавляются новые поля (то есть версии совместимы, если одна версия является префиксом другой).

Давайте посмотрим, какой код AIDL сгенерировал для [структуры `ReceiverInfo`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/ReceiverInfo.aidl):```java
public final void readFromParcel(android.os.Parcel _aidl_parcel)
{
  int _aidl_start_pos = _aidl_parcel.dataPosition();
  int _aidl_parcelable_size = _aidl_parcel.readInt();
  try {
    if (_aidl_parcelable_size < 4) throw new android.os.BadParcelableException("Parcelable too small");;
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    intent = _aidl_parcel.readTypedObject(android.content.Intent.CREATOR);
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    data = _aidl_parcel.readString();
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    extras = _aidl_parcel.readTypedObject(android.os.Bundle.CREATOR);
    // SNIP: Other fields
  } finally {
    if (_aidl_start_pos > (Integer.MAX_VALUE - _aidl_parcelable_size)) {
      throw new android.os.BadParcelableException("Overflow in the size of parcelable");
    }
    _aidl_parcel.setDataPosition(_aidl_start_pos + _aidl_parcelable_size);
  }
}

// check specific to memory type
switch(type) {
    case SENSOR_DIRECT_MEM_TYPE_ASHMEM: { // channel backed by ashmem
        if (resource->numFds < 1) {
            ALOGE("Ashmem direct channel requires a memory region to be supplied");
            android_errorWriteLog(0x534e4554, "70986337");  // SafetyNet
            return nullptr;
        }
        // SNIP: Further validation for SENSOR_DIRECT_MEM_TYPE_ASHMEM
    }
    case SENSOR_DIRECT_MEM_TYPE_GRALLOC:
        // no specific checks for gralloc
        break;
    default:
        ALOGE("Unknown direct connection memory type %d", type);
        return nullptr;
}

native_handle_t *clone = native_handle_clone(resource);
if (!clone) {
    return nullptr;
}
native_handle_set_fdsan_tag(clone);

sp<SensorDirectConnection> conn;
int channelHandle = 0;
if (deviceId == RuntimeSensor::DEFAULT_DEVICE_ID) {
    // SNIP: usual case where sensor belong to this device (not app streaming)
} else {
    auto runtimeSensorCallback = mRuntimeSensorCallbacks.find(deviceId);
    if (runtimeSensorCallback == mRuntimeSensorCallbacks.end()) {
        ALOGE("Runtime sensor callback for deviceId %d not found", deviceId);
    } else {
        int fd = dup(clone->data[0]);
        channelHandle = runtimeSensorCallback->second->onDirectChannelCreated(fd);
    }
}
// SNIP: Return connection

We've got `dup(clone->data[0])` call. `clone` is a `native_handle_t` received from remote process. The native handle contains certain number of FDs and certain number of plain integers within data, amounts of which user of native handle should check by [looking into `numFds` and `numInts`](https://cs.android.com/android/platform/superproject/main/+/main:system/core/libcutils/include/cutils/native_handle.h;l=37-38;drc=efb735f4d5a2f04550e33e8aa9485f906018fe4e) before accessing `data`

Here we even have "check specific to memory type" section which checks that, for `SENSOR_DIRECT_MEM_TYPE_ASHMEM` this is checked here, for `SENSOR_DIRECT_MEM_TYPE_GRALLOC` format of native handle is device specific and cannot be validated here. The thing is that for "runtime sensors" type is always treated as `SENSOR_DIRECT_MEM_TYPE_ASHMEM`, but we can specify `SENSOR_DIRECT_MEM_TYPE_GRALLOC` to bypass validation in that case

This code is however only reachable if "runtime sensors" are present. I'm not sure in what case that really happens, I think it is when user uses "Nearby app streaming" (?)

For testing though, I'm adding small class that allows registration of [`VirtualDevice`](https://developer.android.com/reference/android/companion/virtual/package-summary), you can use it through```sh
adb shell 'CLASSPATH=$(pm path com.example.thisseemswrong | cut -d: -f2) app_process / com.example.thisseemswrong.VirtualDeviceReg'