lsposed/lspromiseAndroid complete exploit chain that enables privilege escalation from a local untrusted app to root/kernel, combination of CVE-2026-49881 and CVE-2026-43284
एक संपूर्ण एक्सप्लॉइट श्रृंखला जो स्थानीय अविश्वसनीय ऐप से 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 संस्करण चलाने वालों को छोड़कर) लेखन के समय कमजोर बने हुए हैं।
श्रृंखला की पहली कमजोरी 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 का एक्सप्लॉइट करने के लिए, हमलावरों को पहले व्हाइटलिस्टेड विशेषाधिकार प्राप्त प्रक्रियाओं में से एक से समझौता करना होगा।