أعلن باحث أمني عن ثغرة جديدة في نواة لينكس تستهدف مكوّن كِف إم (KVM) الخاص بتشغيل الأجهزة الافتراضية على معمارية x86. تكمن خطورتها في أنها قد تسمح لخصم داخل جهاز افتراضي ضمن بيئة افتراضية متداخلة (Nested Virtualization) بالحصول على مسار للهروب من عزل KVM، وصولًا إلى تنفيذ تعليمات على المضيف (Host) بصلاحيات النواة.
الثغرة مُسجّلة تحت المعرّف CVE-2026-64561، وتؤثر—بحسب تحليل الباحث—عندما يكون توسّع الافتراضية المتداخلة مكشوفًا لضيف غير موثوق. وبعبارة أبسط: المشكلة لا تظهر عادةً في سيناريوهات التشغيل “العادية” لضيف واحد، لكنها تصبح ذات معنى عندما تقوم البنية السحابية أو منصة افتراضية بتقديم قدرات افتراضية متداخلة لعملاء لا يمكن الوثوق بهم.
لماذا هذه الثغرة مهمة لمشغّلي السحابة ومراكز البيانات؟
في السنوات الأخيرة، تحولت معماريات السحابة من مجرد “افتراضية” إلى افتراضية متداخلة لتلبية متطلبات التطوير والاختبار، وتشغيل أنظمة تشغيل داخل أنظمة تشغيل، وتشغيل بيئات حاويات أو منصات أتمتة تحتاج إلى خصائص افتراضية. هذه المرونة تأتي بتكلفة أمنية: كلما زادت طبقات العزل، زادت أيضًا مساحة السطح الهجومي في طبقة “الوسيط” (Hypervisor/Kernel Virtualization).
الهجوم هنا ليس مجرد اختراق لضيف افتراضي؛ بل هو محاولة لتجاوز حدود العزل التي يفترض أن تحمي المضيف. وهذا النوع من الثغرات يُعد من أكثر الأنواع حساسية لأنه يهدد موثوقية طبقة النواة نفسها، لا مجرد بيانات داخل VM.
ما المقصود بـ “الهروب من العزل” في سياق KVM؟
عزل KVM مبني على فكرة أن الضيف لا ينبغي أن يملك القدرة على التحكم في المضيف. لكن عندما توجد ثغرة تسمح بتشويه منطق ترجمة الذاكرة أو إدارة هياكل داخلية للنواة الخاصة بالافتراضية، يمكن للمهاجم استغلال ذلك للوصول إلى مسارات تنفيذ حساسة على المضيف. في هذه الحالة، المشكلة مرتبطة بآلية إدارة “ذاكرة الظل” (Shadow Memory) وملحقاتها.
تفصيل التقانة: كيف تعمل ثغرة Zapscape؟
الثغرة—كما وصفها الباحث—هي خلل في ترتيب فحص “الجذر المنتهي” داخل إدارة shadow-MMU في KVM/x86. آلية MMU (وحدة إدارة الذاكرة) هي التي تتعامل مع ترجمة العناوين. أما shadow-MMU في KVM فهي تُنشئ جداول صفحات “ظل” لتسريع ترجمة الذاكرة للضيوف المتداخلة.
الخلل مصنف ضمن CWE-825 (Expired Pointer Dereference)، أي أنه يمكن أن يؤدي إلى استخدام مؤشر/مرجع لم يعد صالحًا. في هذا السيناريو، قد يقوم KVM بإعادة استخدام/إلغاء صفحات MMU أثناء معالجة أخطاء الصفحات الناتجة عن الضيف، ثم يستمر مسار التنفيذ باستخدام “جذر” (root) تم إبطاله بالفعل.
منطق “use-after-free” ولماذا يهم
يشير use-after-free إلى حالة تُستخدم فيها بنية بيانات بعد تحريرها. في سياق النواة، هذا قد يفتح الباب لتلاعب متعمق بالذاكرة أو لربط عناصر في قوائم داخلية بطريقة خاطئة. هنا، يوضح الباحث أن مسار “recursive zap” الذي يقوم KVM بموجبه بإعادة المطالبة بصفحات shadow يمكن أن ينتهي إلى إدخال صفحة في قوائم نشطة ثم تحريرها لاحقًا بينما تبقى مراجع “قديمة” تشير إليها، ما ينتج عنه وصل/تفكيك خاطئ يؤدي إلى كتابة بعد التحرير.
النتيجة العملية: يمكن بناء سلسلة استغلال (chain) تقود—في بيئة اختبار—إلى إنشاء ملف على المضيف بصلاحيات الجذر (أو ما يعادلها على مستوى النواة) باستخدام مسار استغلال مبني على primitive واحد.
من يستهدف؟ وما شروط قابلية الاستغلال؟
وفقًا للباحث، يتطلب الاستغلال أن تكون لديك صلاحيات نواة داخل الضيف L1 (أي غالبًا صلاحيات الجذر داخل جهاز افتراضي “الطبقة الأولى”). هذا الشرط مهم لأنه يغير تقييم المخاطر: الثغرة ليست “عن بعد بالكامل”؛ بل تُقاس خطورتها بمدى قدرة المهاجم على الوصول لصلاحيات عالية داخل VM غير موثوق.
هناك أيضًا شروط إضافية مرتبطة بمعمارية المعالج:
- على أنظمة Intel يلزم تعريض خصائص محددة في EPT (صفحات المشي) بطولي 4 و5 ضمن إعدادات الافتراضية المتداخلة.
- على أنظمة AMD لا يوجد شرط مكافئ بنفس الصياغة، بحسب ما ورد في تحليل الباحث.
كما أن الباحث يذكر أن الثغرة موجودة داخل كِف إم داخل النواة، وليست مرتبطة بالمحرّك الافتراضي QEMU. أي أن QEMU لا يُعد مكوّنًا مُستهدفًا بحد ذاته؛ لكنه قد يُستخدم فقط كبيئة اختبار آمنة (عبر QEMU TCG) لتجنب تعريض الإنتاج للخطر.
ما الذي نعرفه عن “الانتشار في البرية”؟
حتى تاريخ نشر تفاصيل الكشف (6 أغسطس 2026)، لا توجد ادعاءات بأن الثغرة استُخدمت على نطاق واسع في الهجمات الحقيقية. الباحث وصفها بأنها ليست استغلالًا مُسلّحًا يعمل فورًا في بيئات السحابة، لأن الهجوم “الواقعي” يتطلب نقل خطوات L1 إلى وحدة نواة داخل الضيف وتكييف السلسلة مع إعدادات نواة المضيف وخصائص الذاكرة.
هذا التفصيل لا يقلل من خطورتها؛ بل يضعها في فئة “خطر تكتيكي” على بيئات تعطي امتيازات عالية للضيوف غير الموثوقين أو على منصات تطوير/اختبار تشغّل أنظمة ضيوف مع صلاحيات واسعة.
النطاق التقني والتأثير: إصدارات لينكس المتأثرة وإصدارات الإصلاح
وفقًا لقاعدة بيانات NVD، فإن إصدارات لينكس 5.9 وما بعده كانت متأثرة حتى إصدارات الإصلاح المستقرة. وقد وردت أمثلة على إصدارات تم تضمين الإصلاح فيها مثل: 6.6.148 و6.12.101 و6.18.42 و7.1.6 و7.2-rc5.
لكن نقطـة التشغيل لا تتوقف عند “رقم الإصدار”. كثير من توزيعات لينكس تعتمد على آليات backport لإدخال الإصلاحات دون تغيير رقم السلسلة بشكل مباشر. لذلك، أوصت جهات مثل Red Hat بالرجوع إلى تتبع الحزم داخل كل موزع (tracker) وليس فقط إلى مقارنة الإصدارات مع المصدر العلوي.
ماذا تقول توزيعات كبرى؟
- Red Hat: منحت تقييمًا مبدئيًا لـ CVSS 7.0 واعتبرت المشكلة ضمن CWE-825.
- Debian: بحسب حالة المتابعة المذكورة حتى 6 أغسطس 2026، كانت بعض حزم kernel في bullseye وbookworm وtrixie ضمن نطاق “متأثرة” عبر مستودعات الأمان، بينما تم الإبلاغ عن أن sid أصبح “مُصلحًا” بإصدار 7.1.6-1، وأن fork يظل ضمن “متأثر”.
على مستوى الكود، أشير إلى أن الإصلاح في المنبع تم دمجه. والمفتاح التقني في الإصلاح—كما ورد—هو تغيير ترتيب فحص “stale-root check” ليأتي بعد استدعاء make_mmu_pages_available(). وعند اكتشاف أن الجذر تم إبطاله أثناء مسار معالجة خطأ الصفحات، يقوم KVM بإعادة محاولة المعالجة بدل الاستمرار تحت الجذر غير الصالح عبر آلية مثل RET_PF_RETRY.
إطار الامتثال وإدارة المخاطر: كيف تتعامل المؤسسات مع هذا النوع؟
هذا النوع من الثغرات يختبر نضج برنامج إدارة التصحيح (Patch Management) واستراتيجيات تقليل المخاطر في بيئات الافتراضية. على المؤسسات النظر في مواءمة جهودها مع أطر عمل مثل:
- NIST SP 800-53 لإجراءات التحكم في الضوابط الأمنية.
- CIS Controls خصوصًا ما يتعلق بتحديث الأنظمة وإدارة الثغرات.
- OWASP كمرجع عام للحوكمة الأمنية—مع ملاحظة أن OWASP ليس إطارًا خاصًا للهايبرفايزر، لكنه مفيد في صياغة سياسة إدارة المخاطر.
كما أن العديد من المؤسسات تخضع لمتطلبات تنظيمية محلية (بحسب الدولة) تتضمن واجب الإشعار أو إثبات “العناية الواجبة” عند حدوث خلل أمني. والأدق هنا هو اعتماد نهج “الجاهزية للتصحيح” قبل أن تتحول الثغرة إلى حدث استغلال.
ما الذي يجب فعله الآن؟ خطوات عملية لمشغّلي KVM والسحابة
إذا كنت تدير بيئات تستخدم KVM وتعرض الافتراضية المتداخلة لضيوف غير موثوقين، فهذه قائمة مختصرة لكنها عملية:
- تحقق من التوزيعة ومسار الإصلاح: راجع tracker الخاص بموزعك وتأكد أن backport تم تطبيقه فعلًا.
- حدّد ما إذا كانت nested virtualization مكشوفة للضيوف غير الموثوقين. هذا عامل تمييز حاسم في قابلية الاستغلال.
- طبق التحديثات العاجلة على نواة المضيف أو حزم البائع التي تحتوي على الإصلاح.
- قلّل الامتيازات داخل الضيوف: لأن شرط صلاحيات النواة داخل L1 يرفع “عتبة” الهجوم، فإن تقليل الصلاحيات يقلل المخاطر.
- اختبر في بيئة معزولة: استخدم نهج اختبار مثل QEMU TCG كما أوصى الباحث، بدل اختبار مباشر على الأنظمة الإنتاجية.
قراءة أوسع: لماذا تتكرر ثغرات الهروب في طبقة الافتراضية؟
توضح قصة Zapscape اتجاهًا أوسع في الأمن السيبراني: معظم الهجمات الحديثة تستهدف ليس فقط التطبيقات، بل الطبقات العميقة—النواة، أنظمة التشغيل، ومحركات الافتراضية—لأنها تمنح امتيازات أعلى وفرصًا لإدارة الذاكرة بشكل غير مشروع.
في هذا السياق، تُعد ثغرات shadow-MMU من الفئات التي تتكرر عالميًا: لأنها تتعلق بترجمة العناوين والذاكرة المؤقتة داخل بيئة الافتراضية، وهي منطقة حساسة جدًا لأي خطأ في ترتيب فحوصات الصلاحية أو إدارة العمر الافتراضي للكائنات (object lifetime).
وبالعودة إلى خط التطور المذكور في الإفصاح، فإن الباحث سبق أن شارك أعمالًا أخرى في نفس خط العائلة (مثل مشكلات مرتبطة بـ shadow-MMU في منصات KVM على معماريات مختلفة). هذا يوحي بأن “المنطقة” ما زالت نشطة بحثيًا ومفتوحة لمزيد من الاكتشافات—ما يجعل برامج التحديث والمراقبة أكثر أهمية.
سؤال للنقاش
إذا كانت منظمتك تمنح ضيوفًا غير موثوقين وصولًا إلى nested virtualization أو تسمح بامتيازات عالية داخل الأجهزة الافتراضية، فهل تستطيع عمليًا إثبات أنها ستحد من مخاطر ثغرات الهروب من العزل خلال إطار زمني قصير بعد إصدار التصحيح؟
شاركنا: ما هي سياساتكم الحالية لتحديث نواة المضيف في بيئات KVM، وكيف تقيسون المخاطر عندما تكون طبقات الافتراضية المتداخلة جزءًا من الخدمة؟
هاشتاغ: #أمن_سيبراني #KVM #لينكس #الثغرات #الهروب_من_العزل #إدارة_الثغرات #تصحيح_الأنظمة
Leave a Reply