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)` में भी प्रवेश करेंगे जो जल्दी लौट जाता है। वैध सिस्टम उपयोग के दौरान ऐसा कोई मामला नहीं है जहां हम "यदि कोई भिन्न मालिक है, तो हमें कब्ज़ा लेना होगा" पथ में प्रवेश करें

# "कब्ज़ा लेने" पथ को ट्रिगर करना

अपने पिछले एक्सप्लॉइट में मैंने [वह मामला दिखाया था जहाँ `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 संस्करण का उपयोग करके मेरे एमुलेटर पर काम कर गया, हालांकि जब मैंने अधिक हाल के संस्करण के साथ प्रयास किया तो वह योजना [फ़ाइल डिस्क्रिप्टर सैनिटाइज़र (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()` कॉल तक पहुँच भी नहीं पाते। चूंकि सामान्य उपयोग के दौरान "कब्ज़ा लेने" का पथ मृत कोड है, ऐसी समस्याएं अनजान रह सकती हैं

हालांकि, हम `if (obj.cookie != 0)` शर्त देख सकते हैं। यदि यह गलत है तो इसका मतलब है कि `Parcel` के अंदर मौजूद FD वास्तव में उस `Parcel` के स्वामित्व में नहीं है और यह `Parcel` उपयोगकर्ता की जिम्मेदारी है कि वे उन्हें तब तक खुला रखें जब तक वह `Parcel` मौजूद है। लेकिन चूंकि यह `Parcel` अभी-अभी कर्नेल से आया है, `cookie` मान वास्तव में मूल प्रक्रिया से आते हैं और इन्हें अप्रासंगिक माना जाता है जब `Parcel` के पास वास्तव में `mOwner` हो। लेकिन "कब्ज़ा लेने" का पथ वास्तव में इस पर विचार नहीं करता और केवल `cookie` मानों को कॉपी करेगा

इन सबको एक साथ जोड़ते हुए, प्रेषक पक्ष पर `cookie` मानों को शून्य पर सेट करके, हम एक ऐसा `Parcel` प्राप्त कर सकते हैं जो बंद किए गए फ़ाइल डिस्क्रिप्टर को संदर्भित करता है, लेकिन उन्हें अपना स्वामित्व भी नहीं मानता, जिसका अर्थ है कि वह उन्हें फिर से बंद नहीं करेगा। इससे हम FDSan को ट्रिगर करने से बच सकते हैं, हालांकि यह डबल-क्लोज़ शोषण पथों को भी समाप्त कर देता है

# Parcel के Java पक्ष पर चालें

ऐसे FD अभी भी किसी अन्य `Parcel` (और फिर किसी अन्य प्रक्रिया) को पास किए जा सकते हैं, हालांकि ऐसे लटकते FD बनाने का हमारा तरीका रिफ्लेक्शन के माध्यम से `PooledStringWriter` के निर्माण को शामिल करता है, जिसके बाद जब हम इसे `ArrayList<IntentInfo>` में `add()` करने का प्रयास करते हैं तो `ClassCastException` फेंकी जाती है

हमें यह करना होगा:

* `onTransact()` को `data` तर्क के रूप में पारित किए गए `Parcel` के अंत में हों
* `PooledStringWriter` का निर्माण करें, जिसके बाद Parcel में लटकते FD होंगे, लेकिन `ClassCastException` भी फेंकी जाएगी
* उन FD के लिए प्रतीक्षा करें जिन्हें हम लीक करना चाहते हैं, `system_server` के अंदर आवंटित किए जाएं
* उस `Parcel` से FD को किसी अन्य `Parcel` में कॉपी किया जाए जो हमारी प्रक्रिया को भेजा जाएगा

इन सभी आवश्यकताओं को पूरा करने के लिए मुझे पुरानी और नई दोनों तरकीबों का उपयोग करना होगा

## पुरानी तरकीबें

आइए पुरानी तरकीबों पर दोबारा गौर करके शुरू करते हैं, उनमें से अधिकांश को मेरे [`LazyValue`-using-`Parcel`-after-`recycle()` exploit](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`-s को आलसी (lazily) के बजाय उत्सुकता से (eagerly) डिसेरियलाइज़ किया जाता है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=1886-1896;drc=e1841f84f41213879e1f1b45ad4300b96970e545)। यह भी ध्यान देने योग्य है कि उस `Bundle` के अंदर `RemoteViews` के अंतर्गत मौजूद सभी `Bundle`-s भी उत्सुकता से डिसेरियलाइज़ किए जाएंगे, न कि केवल वह जो सीधे `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)। ध्यान दें कि हमारा write-in-`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` संरचना कार्यान्वयन भी उत्पन्न करने में सक्षम है

ये संरचनाएँ लंबाई-उपसर्ग (length-prefixed) होती हैं, इसलिए एक ही संरचना के विभिन्न संस्करण सिस्टम में तब तक संगत होते हैं जब तक बीच में कोई फ़ील्ड नहीं जोड़ी जाती है (अर्थात, संस्करण संगत होते हैं यदि एक संस्करण दूसरे का उपसर्ग है)

आइए देखें कि [`ReceiverInfo` संरचना](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/ReceiverInfo.aidl) के लिए 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` है जो रिमोट प्रक्रिया से प्राप्त होता है। नेटिव हैंडल में डेटा के अंदर निश्चित संख्या में FDs और निश्चित संख्या में सादे पूर्णांक (प्लेन इंटीजर) होते हैं, जिनकी मात्रा नेटिव हैंडल के उपयोगकर्ता को `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'