CVE-2026-0013

ثغرة الوكيل المربك (Confused Deputy) في DocumentsUI على أندرويد - مشروع تحقّق للبحث الأمني

بيان مهم

هذا المستودع هو مستودع بناء مُشتقّ، ويرتبط بالمستودع الرئيسي الأصلي بعلاقة تابعة.

البروتوكول الأمني

قبل الوصول إلى هذا المستودع، تأكّد من قراءة وفهم SECURITY_PROTOCOL.md.

النقاط الرئيسية:

• لا يوفّر هذا المستودع الكود المصدري أو أدوات الهجوم أو أُطر استغلال الثغرات
• نواتج البناء هي عيّنات تحقّق للبحث الأمني، تُستخدم للأغراض الأكاديمية فقط
• أي خسائر مالية أو عواقب قانونية لا علاقة لها بمنشئ المستودع
• المستخدم يتحمّل المسؤولية الكاملة بنفسه

البدء السريع

GitHub Pages: https://XiaoBaiLovesStirring.github.io/cve-2026-0013-poc/

تشغيل البناء: https://github.com/XiaoBaiLovesStirring/cve-2026-0013-poc/actions

الحصول على النواتج: git clone --branch artifacts https://github.com/XiaoBaiLovesStirring/cve-2026-0013-poc.git

نشرة التحديثات

v1.0.4 (2026-08-23) - تشغيل مكوّن مخصص بالوكالة عبر EXTRA_INTENT

التغيير: أصبح targetIntent الذي يُطلقه DocumentsUI بالوكالة يشير إلى المكوّن المخصص الجديد IdTestActivity. يتولّى هذا المكوّن تنفيذ id وكتابة هوية التشغيل والنتيجة في logcat وشريط الإشعارات، للتحقق الفعلي من حقيقتين أساسيتين:

1. هل يستهلك PickActivity في OPPO فعليًا Intent.EXTRA_INTENT ويُطلق المكوّن الهدف بالوكالة؟
2. في أي UID/عملية يعمل المكوّن المُطلَق بالوكالة فعليًا؟

شرح الآلية (مهم): وفقًا لنموذج العزل في أندرويد، فإن أي مكوّن من تطبيق طرف ثالث - بغضّ النظر عمّن أطلقه - يعمل فقط داخل العملية/UID المُعلَن عنها ذاتيًا. بالاعتماد على تشغيل DocumentsUI بالوكالة فقط، سيظل IdTestActivity يعمل بمعرّف UID الخاص بـ com.example.cve20260013exploit (مثل u0_a702/10702)، ولن يتحوّل تلقائيًا إلى uid=10054 الخاص بـ DocumentsUI. للحصول على 10054 لكامل ملف APK، يلزم sharedUserId="android.uid.documentsui" (يتطلب توقيع النظام، وهو غير متاح لأطراف ثالثة) أو بيئة root. تكمن قيمة v1.0.4 في التحقق مما إذا كان EXTRA_INTENT مستهلكًا وتحديد الهوية الحقيقية للتشغيل بالوكالة.

v1.0.3 (2026-08-23) - إصلاح سلسلة التشغيل (تجريد EXTRA_INTENT)

المشكلة: على OPPO/ColorOS، لم يعد PickActivity في DocumentsUI يستهلك Intent.EXTRA_INTENT المُمرَّر من المُستدعي. في الاختبار الفعلي، ظلّ mCallingUid هو معرّف المُستدعي u0_a702، واكتفى PickActivity بعرض واجهة التحديد الخاصة به ثم توقف، دون أي إطلاق بالوكالة للإجراء الهدف بهوية DocumentsUI (uid=10054)، وبذلك انقطعت سلسلة الوكيل المربك الأصلية فعليًا.

الإصلاح (إعادة تصميم سلسلة التشغيل):

• التخلّي عن أسلوب «اسم الفئة المرمّز بشكل ثابت + EXTRA_INTENT»، والتحوّل إلى جعل Activity Resolver في النظام يحلّ DocumentsUI ضمن Intent شرعي (ACTION_OPEN_DOCUMENT / ACTION_GET_CONTENT + CATEGORY_OPENABLE + */*)
• الإبقاء على التسمية الصريحة الاحتياطية لمدخل OPPO المعدَّل picker.PickActivity والمدخل الأصلي PickActivity، لمنع الانهيار عند عدم العثور على المدخل
• التحقق العكسي من هوية مضيف التفويض عبر URI التفويض المؤقت content:// الذي يعيده DocumentsUI (probeUriGrant)، للتحقق من قيام الوكيل المربك من منظور المُفوِّض
• تسجيل نقاط تتبّع لكل مرحلة من سلسلة التشغيل (نتيجة تحليل resolver + المكوّن المُطلق نهائيًا) في logcat وشريط الإشعارات، لتسهيل التأكد من مسار السلسلة مباشرة على الهاتف

شرح الآلية: لا يمكن للتطبيق نفسه أن يجعل عملية DocumentsUI تنفّذ أوامر عشوائية بالوكالة؛ فـ«رفع الامتياز» في الوكيل المربك يتجسّد في جعله يحتفظ/يعيد توجيه نيابةً عنك موارد التفويض التي لا يمكن الحصول عليها إلا بمعرّف uid الخاص به. لذلك تحوّل v1.0.3 إلى التحقق من «من حصل على إذن URI الممنوح من DocumentsUI»، بدلًا من تنفيذ id داخل عملية التطبيق نفسها.

سجل إصلاح البناء: فشل البناء الأول، إذ كان النوع المُرجَع من getPackageManager().resolveActivity() هو ResolveInfo وليس ComponentName، مع الخطأ error: incompatible types: ResolveInfo cannot be converted to ComponentName. تم الإصلاح باستخراج packageName/name من ResolveInfo.activityInfo لإنشاء ComponentName، ثم نجح البناء.

v1.0.2 (2026-08-23) - تنفيذ أمر id وعرضه في شريط الإشعارات

التغيير: تغيّر إجراء إثبات المفهوم من «تشغيل Termux» إلى «تنفيذ أمر id بعد تشغيل سلسلة الوكيل المربك، وعرض النتيجة في شريط إشعارات النظام».

• بعد تشغيل سلسلة الوكيل المربك في DocumentsUI، يتم تنفيذ أمر id داخل التطبيق (محاولة مسارات متعددة: sh -c id وid و/system/bin/id و/system/xbin/id)
• عرض نتائج التنفيذ مثل uid/gid/groups في شريط الإشعارات
• الإبقاء على منطق المدخل الاحتياطي لمداخل المصنّعين المعدَّلة (picker.PickActivity → .PickActivity الأصلي)
• إضافة إذن POST_NOTIFICATIONS لأندرويد 13+ لإرسال الإشعارات

v1.0.1 (2026-08-23) - التكيُّف مع مداخل المصنّعين المعدَّلة

المشكلة: عدّلت عدة شركات مصنّعة (مثل OPPO) مسار فئات DocumentsUI، إذ انتقل المدخل الأصلي com.android.documentsui.PickActivity إلى com.android.documentsui.picker.PickActivity، ما جعل نواتج البناء القديمة غير قادرة على تحديد مدخل استغلال الثغرة على الجهاز المستهدف.

الإصلاح:

• تحديث مدخل الاستغلال الافتراضي إلى com.android.documentsui.picker.PickActivity
• إضافة فحص لتوفر المدخل؛ فإذا لم يكن مدخل الحزمة الفرعية موجودًا، يتم التراجع تلقائيًا إلى المسار الأصلي .PickActivity
• منطق الحكم على التراجع: عند اكتشاف أن المدخل المعدَّل غير متاح، يتم تسجيل سجل (log) ثم محاولة المسار الأصلي

دليل استكشاف فشل البناء (مهم):

• إذا فشل البناء السحابي، اطّلع أولًا على سجلات تشغيل GitHub Actions لتحديد الخطأ المحدد
• إذا كان الخطأ من نوع «تعذّر العثور على المدخل / Activity not found»، فهذا يعني أن المصنّع المستهدف قد عدّل مسار فئات DocumentsUI
• تأكّد بنفسك من اسم فئة المدخل الحقيقي بعد تعديل المصنّع عبر dumpsys package com.android.documentsui أو جدول Activity Resolver Table، ثم عدّل معامل setClassName في ExploitActivity.java وادفع التغيير لبدء إعادة البناء

معلومات الثغرة

CVE-2026-0013 | HIGH (CVSS 8.4) | CWE-441 | Android 14-16 | DocumentsUI PickActivity

نشرة الإصلاح: Android Security Bulletin 2026-03-01