
استغلال إثبات المفهوم لـ CVE-2024-6768، وهي ثغرة في برنامج تشغيل Windows CLFS.sys تؤدي إلى BSoD عبر ملف .BLF مُصمم خصيصًا. يتضمن الكود المصدري وتحليلًا فنيًا.
CVE-2024-6768 هي ثغرة أمنية في برنامج تشغيل نظام ملفات السجل العام (CLFS.sys) في ويندوز، ناتجة عن التحقق غير السليم من الكميات المحددة في بيانات الإدخال. يؤدي هذا الخلل إلى تناقض غير قابل للاسترداد، مما يؤدي إلى تشغيل وظيفة KeBugCheckEx ويؤدي إلى شاشة الموت الزرقاء (BSoD). تؤثر المشكلة على جميع إصدارات ويندوز 10 وويندوز 11، وخادم ويندوز 2016، وخادم 2019، وخادم 2022 حتى مع تطبيق جميع التحديثات. يُظهر إثبات المفهوم (PoC) أنه من خلال صياغة قيم محددة داخل ملف .BLF، يمكن لمستخدم غير مميز التسبب في تعطل النظام. تشمل المشكلات المحتملة عدم استقرار النظام ورفض الخدمة، حيث يمكن للمستخدمين الخبيثين استغلال هذه الثغرة لتعطيل الأنظمة المتأثرة بشكل متكرر، مما يعطل العمليات وربما يؤدي إلى فقدان البيانات.
في آخر جهدين بحثيين على نظام ملفات السجل العام (CLFS)، تمكنت من تحقيق تنفيذ التعليمات البرمجية عن بعد (RCE) في كلتا الحالتين. (إذا كنت مهتمًا، إليك ما قمت به لـ CLFS CVE-2023-28252 و CLFS CVE-2022-37969 ). ومع ذلك، عندما قمت بتعديل بعض القيم في PoC الذي كنت أعمل عليه، لاحظت أنه تسبب في BSoD على النظام المستهدف. وبالتالي، قررت الإبلاغ عن هذه المشكلة. يساعد هذا المستند في فهم BSoD ويقدم إرشادات حول كيفية إعادة إنتاجها.
تنتج هذه الثغرة عن التحقق غير السليم من الكمية المحددة في الإدخال ()
مما يسبب تناقضًا غير قابل للاسترداد في برنامج تشغيل CLFS.sys، مما يجبر على استدعاء وظيفة KeBugCheckEx ، مما يسمح لمستخدم غير مميز بإنتاج BSoD في ويندوز. في هذا المستند، أستخدم CLFS.sys الإصدار 10.0.19041.3324 كمثال، لكن هذه المشكلة تؤثر على جميع الإصدارات حتى أحدث إصدار من ويندوز 10 وويندوز 11 مع تطبيق جميع التحديثات.
النتيجة الأساسية: CVSS 4.0: 6.8 متوسط
سلسلة المتجهات CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
متجه الهجوم (AV): محلي
تعقيد الهجوم (AC): منخفض
متطلبات الهجوم (AT): لا شيء
الصلاحيات المطلوبة (PR): منخفضة
تفاعل المستخدم (UI): لا شيء
السرية (VC): لا شيء
السلامة (VI): لا شيء
التوفر (VA): عالي
السرية (SC): لا شيء
السلامة (SI): لا شيء
التوفر (SA): لا شيء
بعد أن يكتشف النظام الحالة غير القابلة للاسترداد، يستدعي وظيفة KeBugCheckEx مما يؤدي إلى BSoD كما هو موضح من قبل Microsoft في هذه المقالة: < https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-kebugcheckex >.

CClfsLogFcbPhysical::FlushLog+6F2 هو العنوان في CLFS.sys الإصدار 10.0.19041.3324 حيث يتم إنتاج الاستدعاء إلى KeBugCheckEx :
CClfsLogFcbPhysical::FlushLog+6D5
CClfsLogFcbPhysical::FlushLog+6D5 loc_FFFFF8062EED4F35: ; BugCheckParameter2
CClfsLogFcbPhysical::FlushLog+6D5 mov r8d, eax
CClfsLogFcbPhysical::FlushLog+6D8 and [rsp+0A8h+Timeout], 0
CClfsLogFcbPhysical::FlushLog+6DE mov r9, rbx ; BugCheckParameter3
CClfsLogFcbPhysical::FlushLog+6E1 mov edx, 3Ah ; ':' ; BugCheckParameter1
CClfsLogFcbPhysical::FlushLog+6E6 mov ecx, 0C1F5h ; BugCheckCode
CClfsLogFcbPhysical::FlushLog+6EB mov r10, cs:__imp_KeBugCheckEx
CClfsLogFcbPhysical::FlushLog+6F2 call near ptr nt_KeBugCheckEx
لبدء التحليل، من الضروري معرفة تنسيق ملف .BLF، الذي يتم التعامل معه بواسطة برنامج تشغيل نظام ملفات السجل العام الضعيف المسمى CLFS.sys الموجود في المجلد %windir%\system32. لمعرفة المزيد حول هذا، تحقق من قسم المراجع في نهاية هذه المقالة.
في مستودع إثبات المفهوم الخاص بنا، يحتوي ملف 54.blf على قيمة مصممة (0xffffffff00ff01) في الإزاحة 0x1c10.

هذه القيمة المصممة موجودة في الإزاحة 0x38 من بنية _CLFS_CLIENT_CONTEXT ، ويتم نسخها في CClfsLogFcbPhysical::Initialize إلى الإزاحة 0x538 من بنية CClfsLogFcbPhysical .

تبدأ المنطقة المميزة باللون الأزرق أدناه بـ cidNode = 0xC1FDF006 وهي بنية CLFSHASHSYM

بعد ذلك، بدءًا من cidNode == 0xC1FDF007 توجد بنية _CLFS_CLIENT_CONTEXT
في الإزاحة 0x38 يوجد الحقل lsnOwnerPage الذي سيتم ملؤه بالقيمة المصممة 0xffffffff00ff01:
struct _CLFS_CLIENT_CONTEXT { CLFS_NODE_ID cidNode; CLFS_CLIENT_ID cidClient; USHORT fAttributes; ULONG cbFlushThreshold; ULONG cShadowSectors; ULONGLONG cbUndoCommitment; LARGE_INTEGER llCreateTime; LARGE_INTEGER llAccessTime; LARGE_INTEGER llWriteTime; *CLFS_LSN lsnOwnerPage; *// الإزاحة 0x38 CLFS_LSN lsnArchiveTail; CLFS_LSN lsnBase; CLFS_LSN lsnLast; CLFS_LSN lsnRestart; CLFS_LSN lsnPhysicalBase; CLFS_LSN lsnUnused1; CLFS_LSN lsnUnused2; CLFS_LOG_STATE eState; union { HANDLE hSecurityContext; ULONGLONG ullAlignment; }; };
عند تنفيذ PoC، فإنه يصمم قيمة lsnOwnerPage، ويستدعي CreateLogFile ويتم استخدام القيمة المذكورة في UpdateCachedOwnerPage كما هو موضح في مكدس الاستدعاء أدناه:

هذا هو العنوان حيث يستدعي PoC CreateLogFile وتبدأ القيمة المصممة في الاستخدام:



داخل AddLsnOffset يُرجع ulloffset محسوبًا من هذه القيمة المصممة:

ulloffset الذي تم إرجاعه هو 0xFFFFFFFF00000000

بعد ذلك، تتم مقارنة هذه القيمة وتخرج من الوظيفة CClfsLogFcbPhysical::UpdateCachedOwnerPage

بعد ذلك، تعود إلى PoC في وضع المستخدم، وعند الخروج تستدعي CClfsLogFcbPhysical::FlushLog عند استخدام ulloffset المصمم الأصلي

تتم مقارنة هذا في حلقة وإذا لم يكن متساويًا في أي دورة، نظرًا لأن النظام في حالة غير قابلة للاسترداد، فإنه يستدعي KeBugCheck الذي ينتج BSoD لإعادة تشغيل نفسه:


يمكنك العثور على PoC الوظيفي مع المصادر و BLF المصمم على GitHub الخاص بـ Fortra.
آمل أن تجدها مفيدة. يرجى الاتصال بـ < [email protected] > لأي أسئلة.
مراجع نظام ملفات السجل العام (CLFS):