LSPromise

سلسلة استغلال كاملة تتيح تصعيد الامتيازات من تطبيق محلي غير موثوق إلى صلاحيات الجذر/النواة. لا تتضمن هذه السلسلة تلفيات في الذاكرة أو حالات سباق، لذا لا يحتاج المهاجمون إلى تنفيذ عمليات حقن معقدة للكومة أو تجاوز إجراءات الحماية ضد ثغرات تلف الذاكرة مثل KASLR أو MTE أو CFI، مما يجعل سلسلة الاستغلال هذه تحقق نسبة نجاح 100% على الأجهزة المعرضة للخطر.

تم اختبارها على Pixel 10 الذي يعمل بالإصدار الرسمي الأول من Android 17. لاحظ أنها لا تعمل على Pixel 6a وقد تحدث هذه المشكلة أيضًا على أجهزة أخرى تعمل بأنوية 6.1.xxx-android14 بسبب خطأ آخر في هذه الأنوية.

الاستخدام: ثبّت تطبيق KernelSU، افتح هذا التطبيق، انقر على "Run userspace exploit" ثم "Run kernel exploit and load KernelSU". بعد نجاح الاستغلال، سيتم تفعيل KernelSU ويمكنك استخدامه لمنح صلاحيات الجذر لتطبيقات أخرى. مشكلة معروفة: إذا كنت قد نفّذت استغلال النواة بالفعل وتريد تشغيله مرة أخرى، فستحتاج إلى إعادة تشغيل الجهاز.

تسجيل الشاشة: انقر هنا

تقرير فني

تتكون السلسلة من ثغرتين منفصلتين: الأولى ثغرة 0-day في خدمة الاتصالات Telecom، بينما الثانية ثغرة kernel 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 لتحميل كود من تطبيق عشوائي؛ وبينما يبدو أن هناك بعض الإجراءات التي تهدف إلى منع تنفيذ الكود العشوائي، مثل تمرير false إلى Class.forName() لمنع تهيئة الفئة، لا يزال بإمكان التطبيق تعريف AppComponentFactory مخصص يتم استدعاؤه عند استدعاء getClassLoader().

من ناحية أخرى، يوجد الخطأ في InCallController.java، وهو جزء من حزمة com.android.server.telecom وليس com.android.phone. يجدر بالذكر أن الحزمة تُعلن android:sharedUserId="android.uid.system" و android:process="system" في AndroidManifest.xml، لذا فهي تعمل في عملية system_server، وهي واحدة من أكثر عمليات مساحة المستخدم امتيازًا في Android. لذلك، لدينا الآن القدرة على تنفيذ كود Java عشوائي داخل system_server.

من المفاجئ أنه حتى مهندس Google يمكنه ارتكاب مثل هذا الخطأ الكبير في عصر الذكاء الاصطناعي. وجدناه وأبلغناه إلى فريق أمان Android في 23 يوليو 2026. أخبرونا أنه مكرر. قامت Google بتحويل النشرة الأمنية الشهرية إلى إصدار ربع سنوي، مما قد يفسر عدم إصلاح الثغرة بعد 3 أشهر من إصدار Android 17.

تم تخصيص CVE-2026-49881 للثغرة وتم إصلاحها في سبتمبر 2026 عبر إزالة منطق serviceClassExists لمعالجة الثغرة الأمنية.

الوصول إلى حزمة الشبكات

تسمح لنا الثغرة الأولى بتصعيد الامتيازات إلى مستوى النظام system، لكنها لا تزال بعيدة عن الجذر. يتطلب الجذر الكامل على الأقل UID 0 وعدم التقييد بواسطة SELinux.

حان الوقت الآن لتقديم ثغرة kernel 1-day: ثغرات DirtyFrag. لن يتم شرح المبادئ الأساسية هنا بالتفصيل؛ يرجى الرجوع إلى التقرير الفني للمبلّغ الأصلي. هناك نوعان: 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، يجب على المهاجمين أولاً اختراق إحدى العمليات المميزة المدرجة في القائمة البيضاء.

اجمع بين الثغرتين معًا. بينما تسمح لنا ثغرة مساحة المستخدم بتنفيذ كود Java داخل system_server، يمنع 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. ومع ذلك، ليس لدينا su في عالم Android. نشير إلى استغلال polygraphene لـ DirtyPipe لتحويل DirtyFrag إلى تنفيذ كود في النواة على Android:

1. نقوم بتصحيح libc.so و libc++.so و /vendor/lib64/libstagefright_aidl_bufferpool2.so عبر DirtyFrag. libstagefright_aidl_bufferpool2.so مُصنَّف ضمن نطاق vendor_file لذا لا يمكن الوصول إليه من عملية حزمة الشبكات. الحل هو تصحيح /apex/com.android.runtime/bin/crash_dump64 أولاً، وتنفيذه، وبمجرد الانتقال إلى نطاق crash_dump يمكننا فتح libstagefright_aidl_bufferpool2.so.
2. إنشاء وتدمير عملية يتيمة لتحفيز تنفيذ الكود في عملية init. نظرًا لأن libc++.so تم تصحيحه، يتم تنفيذ الكود الخاص بنا بمعرف UID 0 ضمن نطاق init. ثم ننفذ /vendor/bin/modprobe للانتقال إلى نطاق vendor_modprobe.