CVE-2021-0928, android.hardware.camera2.params.OutputConfiguration में writeToParcel/createFromParcel सीरियलाइज़ेशन बेमेल

यह उस कमज़ोरी का उपयोग करने वाला एक्सप्लॉइट है, जो इंस्टॉल किए गए Android ऐप से Android Settings ऐप में विशेषाधिकार वृद्धि (privilege escalation) के लिए है (या किसी अन्य इंस्टॉल किए गए ऐप में, जिसे AndroidManifest.xml में घोषित <receiver> को भेजा जा सकता है; <activity> को भेजकर भी विशेषाधिकार वृद्धि संभव थी, हालाँकि यहाँ प्रस्तुत नहीं की गई है)

मुझे यह समस्या मूल रूप से Android 12 Developer Preview 3 पर मिली

इस रिपॉजिटरी में मौजूद एक्सप्लॉइट संस्करण Android 12 Beta 2 और 3 पर काम करता है

यह कमज़ोरी पहले आधिकारिक Android 12 रिलीज़ में ठीक कर दी गई थी

नीचे लिखा गया विवरण मूल रूप से Google के लिए लिखा गया था, ताकि इस रिपोर्ट को पूर्ण एक्सप्लॉइट श्रृंखला के रूप में विचार किया जा सके

लेखन के समय Android 12 AOSP में उपलब्ध नहीं था (Android Developer Preview/Beta रिलीज़ ओपन सोर्स नहीं हैं)

Parcel का परिचय

Android पर अधिकांश IPC Parcel नामक क्लास के माध्यम से किया जाता है

Parcel का मूल उपयोग इस प्रकार है:```java Parcel p = Parcel.obtain(); p.writeInt(1); p.writeString("Hello");

फिर `Parcel` को [Binder के माध्यम से](https://developer.android.com/reference/android/os/IBinder#transact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)) किसी अन्य प्रक्रिया में भेजा जाता है। वैकल्पिक रूप से, परीक्षण के लिए कोई [`p.setDataPosition(0)`](https://developer.android.com/reference/android/os/Parcel#setDataPosition(int)) को कॉल करके parcel को शुरुआती स्थिति में वापस ला सकता है और पढ़ना शुरू कर सकता है:```java
int a = p.readInt(); // a = 1
String b = p.readString(); // b = "Hello"

यह ध्यान दिया जाना चाहिए कि parcel आंतरिक रूप से उस स्थिति को रखता है जहाँ से reads किए जाते हैं। Parcel class के उपयोगकर्ता की ज़िम्मेदारी है कि वह सुनिश्चित करे कि read* methods पहले उपयोग किए गए write* methods से मेल खाते हों, अन्यथा बाद के reads buffer में गलत स्थितियों से होंगे

Parcel custom objects लिखने की क्षमता भी प्रदान करता है, ऐसा करने का पसंदीदा तरीका Parcelable interface को implement करना है

यहाँ Parcelable interface के implementation का उदाहरण है (अप्रासंगिक कोड हटा दिया गया है, WindowContainerTransaction class का उपयोग exploit में gadget chain के हिस्से के रूप में किया जाता है, हालाँकि इसमें कुछ भी गलत नहीं है)```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);
            }
        };

}

जैसा कि ऊपर देखा जा सकता है, लिखते समय `writeToParcel()` विधि का उपयोग किया जाता है। फिर पढ़ते समय `CREATOR.createFromParcel()` फैक्ट्री विधि को कॉल किया जाता है। यह `Parcelable` कार्यान्वयन की जिम्मेदारी है कि यह सुनिश्चित करे कि `createFromParcel` उतना ही डेटा पढ़े जितना `writeToParcel` द्वारा लिखा गया था, अन्यथा उस `Parcel` से बाद में किए गए सभी रीड गलत ऑफसेट से डेटा पढ़ेंगे

ऐसी क्लास को `Parcel` में/से निम्नलिखित तरीकों से लिखा/पढ़ा जा सकता है:

* सीधे `obj.writeToParcel(parcel, 0)` / `obj = WindowContainerTransaction.CREATOR.createFromParcel()` कॉल करके, इसका उपयोग अक्सर तब किया जाता है जब क्लास का प्रकार ज्ञात हो, उदाहरण के लिए जब `Parcelable` में अलग `Parcelable` का फ़ील्ड हो या AIDL द्वारा जनरेट किए गए कोड में जब परिभाषित RPC विधि में `Parcelable` तर्क के रूप में हो
* `Parcel.writeParcelable`/`readParcelable` के माध्यम से। [`writeParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=1909;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) पहले क्लास का नाम लिखता है और फिर `Parcelable` इंटरफ़ेस से `writeToParcel` विधि को कॉल करता है। [`readParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=3282;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) लिखा गया क्लास नाम पढ़ता है, प्रदान किए गए `ClassLoader` में उस नाम वाली क्लास ढूंढता है या यदि null प्रदान किया गया था तो `BOOTCLASSPATH` में। एक बार क्लास मिल जाने पर उसका स्टैटिक फ़ील्ड `CREATOR` का उपयोग [`Parcelable.Creator`](https://developer.android.com/reference/android/os/Parcelable.Creator) इंस्टेंस प्राप्त करने के लिए किया जाता है जो उस क्लास को पढ़ने के लिए उपयोग की जाने वाली फैक्ट्री है। यह ध्यान रखना महत्वपूर्ण है कि जब `readParcelable` विधि का उपयोग किया जाता है तो यह क्लास पथ में उपलब्ध किसी भी `Parcelable` को पढ़ सकती है क्योंकि बनाई जाने वाली वस्तु का नाम उसी `Parcel` से पढ़ा जाता है
* `readParcelable` का उपयोग कई अन्य `Parcel` विधियों द्वारा किया जाता है, उदाहरण के लिए ऊपर दिए गए उदाहरण में देखा गया `readList` तत्वों को `readValue` के माध्यम से पढ़ता है, जो `Parcel` में वस्तुओं को स्थानांतरित करने का सबसे सामान्य तरीका है और इसके उपयोग के तरीकों में से एक `readParcelable` के माध्यम से है। साथ ही ऊपर दिए गए उदाहरण में Java के Type Erasure के कारण `ArrayList<HierarchyOp> mHierarchyOps` फ़ील्ड वास्तव में Parcel द्वारा समर्थित कोई भी वस्तु रख सकता है, न कि केवल वे जो जेनेरिक प्रकार घोषणा में निर्दिष्ट प्रकार के अनुकूल हैं

# `writeToParcel`/`createFromParcel` बेमेल

जैसा कि ऊपर बताया गया है, यह `Parcelable` इंटरफ़ेस कार्यान्वयन की जिम्मेदारी है कि यह सुनिश्चित करे कि `createFromParcel` `Parcel` से उतना ही डेटा पढ़े जितना मेल खाते `writeToParcel` ने पहले लिखा था। जब भी `BOOTCLASSPATH` में कोई `Parcelable` होता है जो इस अनुबंध का उल्लंघन कर सकता है, यह एक भेद्यता पैदा करता है क्योंकि यह निम्नलिखित परिदृश्य की अनुमति देता है:

1. एक दुर्भावनापूर्ण ऐप `system_server` को एक `Bundle` या `Parcelable` भेजता है जिसमें दोषपूर्ण `Parcelable` इंस्टेंस के साथ-साथ विशेष रूप से निर्मित डेटा होता है जो वास्तव में चरण 3 में पढ़ा जाएगा लेकिन चरण 2 के दौरान शब्दशः पारित किया जाता है
2. `system_server` सत्यापित करता है कि `Bundle` सुरक्षित है और फिर इसे आगे भेजता है या `system_server` प्रदान किए गए `Parcelable` को AIDL विधि में पास करता है जिसमें अगले पैरामीटर में महत्वपूर्ण डेटा भी पारित होता है (यदि उस पैरामीटर में प्राप्त डेटा को संशोधित किया जा सकता है तो यह सुरक्षा समस्या पैदा करेगा)
3. एक अन्य ऐप `system_server` से डेटा प्राप्त करता है और उस पर भरोसा करता है, हालांकि दोषपूर्ण सीरियलाइज़ेशन के कारण वास्तव में जो डेटा वह देखता है वह उस डेटा से भिन्न होता है जो `system_server` भेजने का इरादा रखता था

मैंने उपरोक्त चरणों में "OR" का उपयोग किया है क्योंकि ये चरण दोनों का वर्णन करते हैं: एक [पुराना एक्सप्लॉइट वेरिएंट जो मनमाना Activity शुरू करने की ओर ले जाता है जिसे मैंने 2017 में प्रकाशित किया था](https://github.com/michalbednarski/ReparcelBug) ("OR" के बाईं ओर) और एक नया वेरिएंट जिसका मैं अगले अनुभाग में यहाँ वर्णन करूंगा

# ऐप में `BroadcastReceiver` कैसे निष्पादित होता है