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()` 호출은 (위 코드에서 `mOwner()` 함수 포인터를 통해 호출되는) `IPCThreadState::freeBuffer()`에서 `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`은 수신 트랜잭션 데이터(`onTransact()`에 전달되는 `data` 인자)이거나 수신 reply(`transact()` 호출에 `reply` 인자로 전달된 `Parcel` 객체이며, `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)`에 진입하게 되어 조기 반환이 일어납니다. 그러나 정상적인 시스템 사용 중에는 "다른 소유자가 있다면 소유권을 가져와야 한다" 경로로 진입하는 경우가 없습니다.

# "소유권 가져오기" 경로 트리거하기

이전 익스플로잇 중 하나에서 [`createFromParcel()`이 실제로는 읽어야 할 `Parcel`에 대해 `writeInt(0)`을 호출할 수 있는 사례](https://github.com/michalbednarski/TheLastBundleMismatch#side-effects)를 보여준 적이 있습니다. 그 수정으로 `AccountManagerService` 내에서 `Intent`가 아닌 `createFromParcel()` 메서드의 실행은 차단되었지만, `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" 경로를 트리거하려면 `onTransact()`에 `data`로 전달된 `Parcel`에 대해 임의의 `readParcelable` 호출이 필요합니다. 이 익스플로잇에서는 [이전에 다른 익스플로잇에서 사용했던 동일한 경로](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()`는 데이터를 제자리에서 덮어쓰려 시도할 것이고, `/dev/binder` `mmap`으로 뒷받침되는 데이터의 경우 `SIGSEGV`가 발생했을 것입니다.

# 파일 디스크립터 샌나타이저

제 초기 아이디어는 "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 적용 범위가 `Parcel` 내부의 FD까지 확장되었습니다](https://android.googlesource.com/platform/frameworks/native/+/7772039cc5084247450f6113d9a18eca17f672aa%5E!/).

실제로 FDSan이 Parcel을 적용한 후에는 `Parcel`에 FD가 포함된 경우 `closeFileDescriptors()` 호출에 도달할 수조차 없었습니다. 그 호출 이전에 `acquireObjects();` 호출이 있는데, 이는 `Binder` 핸들에 대한 참조를 획득하며(해당 함수 내에서 나중에 `mOwner()` 호출에 의해 해제됩니다), 그러나 `acquireObjects()`는 또한 [FD에 대한 FDSan 태그를 설정합니다](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()` 호출에 도달하지도 못했습니다. "소유권 이전( take possession )" 경로는 정상적인 사용 중에는 죽은 코드(dead code)이므로 이러한 문제는 눈에 띄지 않을 수 있습니다

하지만 `if (obj.cookie != 0)` 조건을 볼 수 있습니다. 이 조건이 거짓이면 `Parcel` 내에 존재하는 FD가 실제로 해당 `Parcel`에 의해 소유되지 않는다는 뜻이며, 해당 `Parcel`이 존재하는 동안 FD를 계속 열어 둘 책임은 `Parcel` 사용자에게 있습니다. 그러나 이 `Parcel`은 방금 커널에서 왔기 때문에 `cookie` 값은 실제로 원래 프로세스에서 온 것이며 `Parcel`에 실제로 `mOwner`가 있을 때는 관련이 없는 것으로 간주됩니다. 하지만 "소유권 이전" 경로는 이를 실제로 고려하지 않고 `cookie` 값을 그대로 복사할 뿐입니다

이 모든 것을 종합하면, 송신자 측에서 `cookie` 값을 0으로 설정함으로써, 닫힌 파일 디스크립터를 참조하지만 소유하고 있다고 간주되지 않는 `Parcel`을 얻을 수 있으며, 이는 다시 닫지 않는다는 것을 의미합니다. 이를 통해 FDSan을 건드리지 않을 수 있지만, 동시에 이중 닫기(double-close) 공격 경로도 제거됩니다

# Parcel의 Java 측 트릭

이러한 FD는 여전히 다른 `Parcel`(그리고 다른 프로세스)로 전달될 수 있지만, 우리가 이러한 매달린(dangling) FD 생성을 트리거하는 방식은 리플렉션을 통한 `PooledStringWriter` 생성 후 `ArrayList<IntentInfo>`에 `add()`하려고 할 때 `ClassCastException`이 발생하는 것을 포함합니다

다음이 필요합니다:

* `onTransact()`의 `data` 인자로 전달된 `Parcel`의 끝에 있어야 함
* `PooledStringWriter` 생성을 수행하여, 그 후 Parcel이 매달린 FD를 갖게 되지만 `ClassCastException`도 발생해야 함
* 누출하려는 FD가 `system_server` 내에서 할당될 때까지 기다려야 함
* 해당 `Parcel`의 FD가 우리 프로세스로 전송될 다른 `Parcel`에 복사되어야 함

이 모든 요구 사항을 충족하려면 이전 트릭과 새로운 트릭을 모두 사용해야 합니다

## 이전 트릭

이전 트릭을 다시 살펴보는 것부터 시작하겠습니다. 대부분은 이미 제 [`LazyValue`-`Parcel`-`recycle()`-후-사용-공격](https://github.com/michalbednarski/LeakValue)에서 설명했습니다

1. [`RemoteViews` 클래스는 `Parcel.ReadWriteHelper`가 설정된 상태로 포함된 `Bundle`의 역직렬화를 수행합니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/RemoteViews.java;l=2287-2300;drc=9b2e54f25456f2726ab1a15e6b6dc19395a3b5b4). [`ReadWriteHelper`가 설정되면 `Bundle`은 지연(lazily) 역직렬화되지 않고 즉시(eagerly) 역직렬화됩니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=1886-1896;drc=e1841f84f41213879e1f1b45ad4300b96970e545). 또한 이 시점에서 `RemoteViews` 아래 해당 `Bundle` 내에 포함된 모든 `Bundle`도 직접 `RemoteViews` 안에 있는 하나만이 아니라 즉시 역직렬화된다는 점에 주목할 만합니다
2. [`system_server` 내에서 `Bundle` 역직렬화 중 `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` 클래스는 역직렬화 중에 직렬화된 데이터에 지정된 객체로 차단(blocking) 발신 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` 구조체 구현을 생성할 수도 있습니다

이러한 구조체는 길이-접두사(length-prefixed) 방식이므로, 필드가 중간에 추가되지 않는 한 동일 구조체의 서로 다른 버전은 시스템 내에서 호환됩니다. 즉, 한 버전이 다른 버전의 접두사(prefix)이면 버전이 호환됩니다

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

`dup(clone->data[0])` 호출이 있습니다. `clone`은 원격 프로세스에서 받은 `native_handle_t`입니다. 네이티브 핸들은 데이터 안에 일정 개수의 FD와 일정 개수의 일반 정수를 포함하며, 네이티브 핸들 사용자는 `data`에 접근하기 전에 [ `numFds`와 `numInts` 확인](https://cs.android.com/android/platform/superproject/main/+/main:system/core/libcutils/include/cutils/native_handle.h;l=37-38;drc=efb735f4d5a2f04550e33e8aa9485f906018fe4e)을 통해 그 개수를 확인해야 합니다.

여기에는 "메모리 유형별 검사" 섹션도 있는데, `SENSOR_DIRECT_MEM_TYPE_ASHMEM`의 경우 여기서 검사되고, `SENSOR_DIRECT_MEM_TYPE_GRALLOC`의 경우 네이티브 핸들 형식이 기기별로 다르므로 여기서 검증할 수 없습니다. 문제는 "런타임 센서"의 경우 유형이 항상 `SENSOR_DIRECT_MEM_TYPE_ASHMEM`으로 처리되지만, 이 경우 `SENSOR_DIRECT_MEM_TYPE_GRALLOC`을 지정하면 검증을 우회할 수 있다는 점입니다.

그러나 이 코드는 "런타임 센서"가 존재할 때만 도달할 수 있습니다. 실제로 어떤 경우에 그런 일이 발생하는지 확실하지 않으며, 사용자가 "Nearby app streaming(주변 앱 스트리밍)"을 사용할 때인 것 같습니다(?).

테스트를 위해 [`VirtualDevice`](https://developer.android.com/reference/android/companion/virtual/package-summary) 등록을 허용하는 작은 클래스를 추가하고 있습니다. 다음과 같이 사용할 수 있습니다.```sh
adb shell 'CLASSPATH=$(pm path com.example.thisseemswrong | cut -d: -f2) app_process / com.example.thisseemswrong.VirtualDeviceReg'