LSPromise

एक संपूर्ण एक्सप्लॉइट श्रृंखला जो स्थानीय अविश्वसनीय ऐप से root/kernel तक विशेषाधिकार वृद्धि (privilege escalation) को सक्षम बनाती है। इसमें मेमोरी करप्शन या रेस कंडीशन शामिल नहीं हैं, इसलिए हमलावरों को जटिल हीप स्प्रेइंग करने या KASLR, MTE या CFI जैसी मेमोरी करप्शन कमजोरियों के विरुद्ध मिटिगेशन को बायपास करने की आवश्यकता नहीं होती, जिससे यह एक्सप्लॉइट श्रृंखला कमजोर डिवाइसों पर 100% सफलता दर प्राप्त करती है।

प्रारंभिक Android 17 आधिकारिक रिलीज़ चलाने वाले Pixel 10 पर परीक्षण किया गया। ध्यान दें कि यह Pixel 6a पर काम नहीं करता है और यह समस्या इन कर्नेलों में एक अन्य बग के कारण 6.1.xxx-android14 कर्नेल ट्री चलाने वाले अन्य डिवाइसों पर भी हो सकती है।

उपयोग: KernelSU ऐप इंस्टॉल करें, यह ऐप खोलें, "Run userspace exploit" पर क्लिक करें फिर "Run kernel exploit and load KernelSU" पर क्लिक करें। सफल एक्सप्लॉइटेशन के बाद, KernelSU सक्रिय हो जाएगा और आप इसका उपयोग अन्य ऐप्स को root एक्सेस देने के लिए कर सकते हैं। ज्ञात समस्या: यदि आप पहले ही कर्नेल एक्सप्लॉइट चला चुके हैं और इसे फिर से चलाना चाहते हैं, तो आपको डिवाइस को रीबूट करना होगा।

स्क्रीन रिकॉर्डिंग: यहाँ क्लिक करें

राइटअप

यह श्रृंखला दो अलग-अलग कमजोरियों से बनी है: एक Telecom सेवा में 0-day है, जबकि दूसरी कर्नेल 1-day है जिसे 3 महीने पहले खुलासा किया गया था। लेकिन AOSP और Pixel डिवाइस (बीटा QPR संस्करण चलाने वालों को छोड़कर) लेखन के समय कमजोर बने हुए हैं।

system_server में प्रवेश करना

श्रृंखला की पहली कमजोरी Android 17 में पेश किया गया एक सरल लॉजिक बग है। इसकी उत्पत्ति एक अजीब परिवर्तन से होती है, जो InCallController.java में निम्नलिखित कोड जोड़ता है:

        PackageManager packageManager = mContext.getPackageManager();
        Context userContext = mContext.createContextAsUser(userHandle,
                0 /* flags */);
        PackageManager userPackageManager = userContext != null ?
                userContext.getPackageManager() : packageManager;

        List<ResolveInfo> entries;
        entries = userPackageManager.queryIntentServices(
                serviceIntent,
                PackageManager.GET_META_DATA | PackageManager.MATCH_DISABLED_COMPONENTS);
        for (ResolveInfo entry : entries) {
            ServiceInfo serviceInfo = entry.serviceInfo;

            if (serviceInfo != null) {
                boolean isMetaFlag = serviceInfo.metaData != null &&
                        serviceInfo.metaData.getBoolean(
                                "android.telecom.CLASS_EXISTENCE_CHECK", false);
                if (isMetaFlag && !serviceClassExists(serviceInfo, userHandle)) {
                    continue;
                }
            }
        }

प्रासंगिक serviceClassExists() विधि निम्नानुसार परिभाषित है:

    /**
     * Verifies that the class for a given ServiceInfo exists within its package.
     * This prevents a system crash if a service is declared in the manifest but its
     * class was not included in the compiled code.
     * @param serviceInfo The ServiceInfo of the service to check.
     * @param userHandle The user under which to check for the service.
     * @return {@code true} if the class exists, {@code false} otherwise.
     */
    private boolean serviceClassExists(ServiceInfo serviceInfo, UserHandle userHandle) {
        Log.i(this, "serviceClassExists check");
        try {
            Context packageContext = mContext.createPackageContextAsUser(
                    serviceInfo.packageName,
                    Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY, userHandle);
            ClassLoader classLoader = packageContext.getClassLoader();
            Class.forName(serviceInfo.name, false, classLoader);
            return true;
        } catch (NameNotFoundException | ClassNotFoundException e) {
            Log.w(this, "Skipping InCallService: class not found for " + serviceInfo.name);
            return false;
        } catch (Exception e) {
            Log.e(this, e, "Error checking for existence of " + serviceInfo.name);
            return false;
        }
    }

यह सबसे अविश्वसनीय कमजोरी है जो मैंने कभी देखी है। कोड किसी मनमाने ऐप से कोड लोड करने के लिए Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY का उपयोग करता है; हालाँकि मनमाने कोड निष्पादन को रोकने के लिए कुछ उपाय प्रतीत होते हैं, जैसे क्लास इनिशियलाइज़ेशन को रोकने के लिए Class.forName() को false पास करना, फिर भी ऐप एक कस्टम AppComponentFactory घोषित कर सकता है जो getClassLoader() कॉल होने पर आमंत्रित किया जाता है।

दूसरी ओर, बग InCallController.java में मौजूद है, जो com.android.phone के बजाय com.android.server.telecom पैकेज का हिस्सा है। यह ध्यान देने योग्य है कि पैकेज AndroidManifest.xml में android:sharedUserId="android.uid.system" और android:process="system" घोषित करता है, इसलिए यह system_server प्रक्रिया में चलता है, जो Android में सबसे विशेषाधिकार प्राप्त यूज़रस्पेस प्रक्रियाओं में से एक है। इसलिए, अब हमारे पास system_server के अंदर मनमाना Java कोड निष्पादित करने की क्षमता है।

यह आश्चर्य की बात है कि AI युग में भी एक Google इंजीनियर इतनी बड़ी गलती कर सकता है। हमने इसे 23 जुलाई, 2026 को Android सुरक्षा टीम को पाया और रिपोर्ट किया। उन्होंने हमें बताया कि यह एक डुप्लिकेट था। Google ने मासिक सुरक्षा बुलेटिन को त्रैमासिक रिलीज़ में बदल दिया है, जो यह समझा सकता है कि Android 17 की रिलीज़ के 3 महीने बाद भी कमजोरी को ठीक क्यों नहीं किया गया।

कमजोरी को CVE-2026-49881 सौंपा गया था और सितंबर 2026 में सुरक्षा कमजोरी को संबोधित करने के लिए serviceClassExists लॉजिक को हटाकर ठीक किया गया।

नेटवर्क स्टैक में प्रवेश करना

पहला बग हमें system तक विशेषाधिकार बढ़ाने की अनुमति देता है, लेकिन root से अभी भी बहुत दूर है। एक पूर्ण root के लिए कम से कम UID 0 की आवश्यकता होती है और SELinux द्वारा प्रतिबंधित नहीं होना चाहिए।

अब कर्नेल 1-day का परिचय देने का समय है: DirtyFrag कमजोरियाँ। अंतर्निहित सिद्धांतों का यहाँ विस्तार से वर्णन नहीं किया जाएगा; कृपया मूल रिपोर्टर के राइटअप को देखें। 2 प्रकार हैं: CVE-2026-43500 के लिए RxRPC की आवश्यकता होती है जो Android जेनेरिक कर्नेल के लिए अक्षम है; CVE-2026-43284 के लिए xfrm-ESP की आवश्यकता होती है और यह Android पर एक्सप्लॉइटेबल है। हालाँकि, SELinux अविश्वसनीय ऐप्स को उस सुविधा का उपयोग करने से रोकता है:

# Privileged netlink socket interfaces.
neverallow { appdomain -network_stack }
    domain:{
        netlink_tcpdiag_socket
        netlink_nflog_socket
        netlink_xfrm_socket
        netlink_audit_socket
        netlink_dnrt_socket
    } *;

केवल अनुमत डोमेन हैं system_server, network_stack और netd। DirtyFrag का एक्सप्लॉइट करने के लिए, हमलावरों को पहले व्हाइटलिस्टेड विशेषाधिकार प्राप्त प्रक्रियाओं में से एक से समझौता करना होगा।

दोनों बगों को मिलाएँ। जबकि यूज़रस्पेस बग हमें system_server के अंदर Java कोड निष्पादित करने की अनुमति देता है, SELinux system_server को /data से नेटिव लाइब्रेरी लोड करने या अनाम निष्पादन योग्य मेमोरी मैप करने से भी रोकता है। यह नेटिव कोड का उपयोग करना असंभव बना देता है, जिससे एक्सप्लॉइटेशन की कठिनाई बढ़ जाती है। इसलिए com.android.networkstack के अंदर कोड निष्पादित करना बेहतर होगा, जो हमारे APK से नेटिव कोड लोड कर सकता है और DirtyFrag का एक्सप्लॉइट करने के लिए पर्याप्त विशेषाधिकार रखता है।

सौभाग्य से, system_server वह प्रक्रिया है जहाँ ActivityManager चलता है। ActivityManager प्रत्येक ऐप प्रक्रिया के IApplicationThread हैंडल को एक Java मैप में संग्रहीत करता है और चूँकि हम ActivityManager की同一 प्रक्रिया के रूप में चलते हैं, हम Java रिफ्लेक्शन का उपयोग करके उन्हें प्राप्त कर सकते हैं। इसके साथ, हम com.android.networkstack को मनमाने कमांड भेज सकते हैं ताकि उसे हमारा कोड लोड करने के लिए मजबूर किया जा सके। इस ट्रिक के बारे में अधिक जानकारी के लिए, कृपया CVE-2026-0091 के लिए मेरा पिछला एक्सप्लॉइट देखें।

कर्नेल में प्रवेश करना

DirtyFrag केवल-पठनीय फ़ाइलों को ओवरराइट करने की अनुमति देता है। यह Linux दुनिया में एक शक्तिशाली प्रिमिटिव है, क्योंकि हम su बाइनरी को ओवरराइट कर सकते हैं जिसमें SUID बिट होता है। हालाँकि, Android दुनिया में हमारे पास su नहीं है। हम Android पर DirtyFrag को कर्नेल कोड निष्पादन में बदलने के लिए DirtyPipe के लिए polygraphene के एक्सप्लॉइट का संदर्भ लेते हैं:

1. हम DirtyFrag के माध्यम से libc.so, libc++.so और /vendor/lib64/libstagefright_aidl_bufferpool2.so को पैच करते हैं। libstagefright_aidl_bufferpool2.so को vendor_file डोमेन के रूप में लेबल किया गया है इसलिए इसे नेटवर्क स्टैक प्रक्रिया से एक्सेस नहीं किया जा सकता। समाधान यह है कि पहले /apex/com.android.runtime/bin/crash_dump64 को पैच करें, इसे निष्पादित करें, और एक बार जब हम crash_dump डोमेन में संक्रमण कर लें तो हम libstagefright_aidl_bufferpool2.so खोल सकते हैं।
2. init प्रक्रिया में कोड निष्पादन ट्रिगर करने के लिए एक अनाथ प्रक्रिया बनाएँ और नष्ट करें। क्योंकि libc++.so पैच किया गया है, हमारा कोड init डोमेन के साथ UID 0 के रूप में निष्पादित होता है। फिर हम vendor_modprobe डोमेन में संक्रमण के लिए निष्पादित करते हैं।