CVE-2019-2215 (Bad Binder) — एक्सप्लॉइट विश्लेषण

यह रिपॉजिटरी CVE-2019-2215 (Bad Binder) भेद्यता पर शोध और Kotlin/Jetpack Compose के साथ Android के लिए एक कार्यशील प्रोटोटाइप एक्सप्लॉइट लिखने का एक छोटा परीक्षण प्रोजेक्ट है।

README में मैं:

1. एक्सप्लॉइट प्रोटोटाइप के लिए पर्यावरण तैयार करने और चलाने का वर्णन करता हूँ।
2. CVE-2019-2215 के शोषण के मुख्य चरणों का विश्लेषण करता हूँ और उन्हें C कोड में विशिष्ट कार्यों से मैप करता हूँ।
3. अलग से उन कठिनाइयों को सूचीबद्ध करता हूँ जिनका मुझे रास्ते में सामना करना पड़ा और मैंने उन्हें कैसे हल किया।

---

तैयार APK (GitHub Actions)

रिपॉजिटरी में एक GitHub Actions वर्कफ़्लो कॉन्फ़िगर किया गया है, जो प्रत्येक push/PR पर ./gradlew assembleDebug कमांड के साथ प्रोजेक्ट बनाता है और तैयार badbinder-debug.apk को एक आर्टिफैक्ट के रूप में प्रकाशित करता है।

इसे इस प्रकार डाउनलोड किया जा सकता है:

1. रिपॉजिटरी में Actions टैब खोलें।
2. वांछित वर्कफ़्लो रन चुनें।
3. पेज के नीचे Artifacts अनुभाग ढूँढें और निर्मित APK के साथ badbinder-debug-apk संग्रह लें।

यह सुविधा के लिए किया गया है, यदि कोई स्थानीय वातावरण सेट किए बिना बस एप्लिकेशन का परीक्षण करना चाहता है।

---

भेद्यता के बारे में संक्षेप में

CVE-2019-2215 Android कर्नेल की Binder IPC उपप्रणाली में एक Use-After-Free (UAF) है।

सरलीकृत:

• कर्नेल में एक संरचना struct binder_thread है जो Binder कॉल करने वाले थ्रेड का वर्णन करती है;
• इस संरचना को मुक्त (free) किया जा सकता है, लेकिन कॉल के एक निश्चित क्रम के तहत यह अभी भी प्रतीक्षा सूचियों (waitqueue) में बनी रहती है;
• बाद में कर्नेल remove_wait_queue में पहले से मुक्त मेमोरी के साथ काम करने का प्रयास करता है, जो एक क्लासिक UAF परिदृश्य खोलता है;
• यदि वातावरण और बाद के आवंटन को सावधानीपूर्वक चुना जाए, तो कर्नेल को मनमाने पतों पर पढ़ने/लिखने के लिए मजबूर किया जा सकता है, और फिर कर्नेल विशेषाधिकार और फिर userspace में root प्राप्त किया जा सकता है।

अधिक विस्तृत सैद्धांतिक विश्लेषण मैंने सामग्री के अनुसार किया:

1. https://cloudfuzz.github.io/android-kernel-exploitation/
2. https://dayzerosec.com/blog/2019/11/07/analyzing-androids-cve-2019-2215-dev-binder-uaf.html
3. https://hernan.de/blog/tailoring-cve-2019-2215-to-achieve-root/

---

1. पर्यावरण तैयार करना और एक्सप्लॉइट प्रोटोटाइप चलाना

1.1. वर्चुअल डिवाइस का चयन और तैयारी

असाइनमेंट के अनुसार Android 10.0 (Q) x86_64 इमेज वाले AVD का उपयोग करने की सिफारिश की गई है।
मैंने निम्नलिखित किया:

1. Android Studio में एक AVD बनाया (Pixel डिवाइस, Android 10 (Q), x86_64)।
2. सुनिश्चित किया कि इमेज में Binder सक्षम है और /dev/binder डिवाइस मौजूद है।
3. USB/ADB डिबगिंग सक्षम की और डिवाइस तक पहुँच की जाँच की:

   adb shell
   ls -l /dev/binder
   

इस स्तर पर मुझे एक अप्रिय तथ्य का सामना करना पड़ा:
वर्तमान में आधुनिक AVD इमेज पहले से पैच किए गए कर्नेल के साथ आती हैं, जिसमें CVE-2019-2215 बंद कर दी गई है। अर्थात्, आधुनिक आधिकारिक एमुलेटर पर वास्तव में root प्राप्त करना संभव नहीं होगा — एक्सप्लॉइट बाद के चरणों में विफल हो जाता है या बस विशेषाधिकार वृद्धि नहीं देता।

अंततः मैं AVD का उपयोग एक्सप्लॉइट के तर्क को पुन: प्रस्तुत करने के लिए प्रशिक्षण उपकरण के रूप में करता हूँ:

• मुझे सिस्टम कॉल के समान अनुक्रम मिलते हैं,
• मैं UAF प्रयासों, पता लीक और addr_limit को अधिलेखित करने के प्रयास का निरीक्षण करता हूँ,
• लेकिन वर्तमान, पैच किए गए कर्नेल पर अंतिम "root प्राप्त करना" स्वाभाविक रूप से काम नहीं करता (और यह अपेक्षित है)।

यह एक महत्वपूर्ण बारीकियाँ है: नीचे दिया गया सभी कोड और रिपोर्ट शैक्षिक हैं, 'लड़ाकू' नहीं।

---

1.2. मूल एक्सप्लॉइट के साथ Android एप्लिकेशन का निर्माण

मैंने एक छोटा Android एप्लिकेशन बनाया:

• UI Kotlin + Jetpack Compose पर,
• Native भाग C में JNI के माध्यम से — वास्तविक एक्सप्लॉइट कोड,
• उनके बीच संचार JNI कॉलबैक के माध्यम से, ताकि C कोड से स्ट्रिंग सीधे UI में आ सकें।

मुख्य चरण:

1. Android Studio में एक सामान्य प्रोजेक्ट बनाया (Kotlin, न्यूनतम Android 10 समर्थन)।

2. NDK और CMake को जोड़ा।

3. एक्सप्लॉइट के साथ एक मूल फ़ाइल जोड़ी (वही cve-2019-2215.c जिसमें फ़ंक्शन leak_task_struct, overwrite_addr_limit, आदि हैं)।

4. CMakeLists.txt में libcve-2019-2215.so का निर्माण जोड़ा।

5. MainActivity में:

   init {
       System.loadLibrary("cve-2019-2215")
   }
   
   external fun runNativeExploit(): String
   external fun setNativeLogger(logger: NativeLogger)
   

6. Kotlin पक्ष पर ExploitViewModel बनाया, जो NativeLogger इंटरफ़ेस को लागू करता है और सभी संदेशों को StateFlow<List<String>> में संग्रहीत करता है। UI इस प्रवाह की सदस्यता लेता है और 'टर्मिनल' में लॉग प्रदर्शित करता है।

गतिविधि शुरू होने पर मैं setNativeLogger(viewModel) कॉल करता हूँ ताकि मूल कोड को वह ऑब्जेक्ट मिल जाए जिसमें स्ट्रिंग भेजी जा सकें।

---

1.3. लॉन्च और उपयोग परिदृश्य

1. एप्लिकेशन बनाएँ और स्थापित करें:

   ./gradlew installDebug
   

2. AVD और स्वयं एप्लिकेशन लॉन्च करें।

3. स्क्रीन पर मुझे एक 'टर्मिनल' और एक RUN EXPLOIT बटन दिखाई देता है।

4. दबाने पर:

   • Kotlin पृष्ठभूमि थ्रेड में runNativeExploit() कॉल करता है।
   • C कोड एक्सप्लॉइट के सभी चरणों को निष्पादित करना शुरू करता है और चरणों को लॉग करता है।
   • JNI कॉलबैक के माध्यम से लॉग ViewModel में आता है और Compose-UI में प्रदर्शित होता है।

वास्तविक कमजोर कर्नेल पर मैं अंत में कुछ इस प्रकार देखने की उम्मीद करूँगा:

[+] Selinux changed: Permissive now.
[+] Root escalation successful!
uid=0(root)...

वर्तमान Android 10 एमुलेटर पर, निश्चित रूप से, ऐसा नहीं होता है, लेकिन बाकी सब कुछ — task_struct लीक, addr_limit को अधिलेखित करने का प्रयास, cred और kernel_base की गणना — एक 'परिदृश्य' के रूप में काम करता है, जो असाइनमेंट के लिए आवश्यक था।

---

2. एक्सप्लॉइट के मुख्य चरणों का विश्लेषण और कोड के साथ मैपिंग

नीचे विशिष्ट C फ़ंक्शन से जुड़ा एक्सप्लॉइट का तार्किक आरेख है।

2.1. एक्सप्लॉइट का सामान्य परिदृश्य

उच्च-स्तरीय योजना इस प्रकार है:

1. struct binder_thread ऑब्जेक्ट पर UAF बनाएँ और इसका उपयोग करके अपनी प्रक्रिया के task_struct का पता लीक करें (leak_task_struct)।
2. दूसरे UAF चक्र और सावधानीपूर्वक चुनी गई संरचनाओं के साथ task_struct में addr_limit फ़ील्ड को अधिलेखित करें (overwrite_addr_limit) — इससे आगे copy_to_user / copy_from_user के लिए user-space और kernel-space पतों के बीच की बाधा हट जाती है।
3. पाइप का उपयोग करके कर्नेल मेमोरी का मनमाना पढ़ना/लिखना लागू करें (arb_read / arb_write)।
4. इसका उपयोग करके वर्तमान प्रक्रिया के cred और कर्नेल बेस का पता लगाएँ (verifying), फिर:
   • SELinux बंद करें (selinux_enforcing = 0),
   • root बनने और पूर्ण क्षमता सेट प्राप्त करने के लिए cred फ़ील्ड को अधिलेखित करें (runNativeExploit)।

समानांतर में, मैंने JNI लॉगर को एकीकृत किया ताकि ये सभी चरण सीधे UI में दिखाई दें।

---

2.2. चरण 1 — task_struct पता लीक (leak_task_struct)

मुख्य फ़ंक्शन:

void leak_task_struct() {
    android_log("[*] Starting leak_task_struct...");

    cpu_set_t cpu_set;
    CPU_ZERO(&cpu_set);
    CPU_SET(0, &cpu_set);
    ret = sched_setaffinity(0, sizeof(cpu_set), &cpu_set);
    assert(ret >= 0);
    ...
}

फ़ंक्शन क्या करता है:

1. थ्रेड को CPU 0 पर फिक्स करता है (sched_setaffinity), ताकि कर्नेल आवंटक का व्यवहार अधिक पूर्वानुमेय हो। यह UAF शोषण की स्थिरता में सुधार करता है।

2. /dev/binder खोलता है, epoll डिस्क्रिप्टर बनाता है:

   fd = open("/dev/binder", O_RDONLY);
   epfd = epoll_create(1000);
   

   Binder डिस्क्रिप्टर epoll में पंजीकृत होता है:

   epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
   

3. struct iovec iov_buffers[IOVEC_N] की एक सरणी तैयार करता है और मेमोरी आवंटित करता है:

   spinner = mmap((void *)0x100000000, page_size, PROT_READ | PROT_WRITE,
                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
   

   यहाँ यह महत्वपूर्ण है कि पते के निचले 32 बिट शून्य हों:

   if (((long) spinner & 0xffffffff) != 0) {
       android_log("[!] mmap returned wrong address!");
       return;
   }
   

   यह शोषण लेखों की तकनीक से मेल खाता है: आगे कर्नेल हमारे डेटा के एक हिस्से की व्याख्या पॉइंटर्स वाली संरचनाओं के रूप में करता है, और ऐसा 'अच्छी तरह से संरेखित' पता दुरुपयोग को सरल करता है।