ثغرة زابسكيب في KVM قد تسمح بهروب آلة افتراضية بصلاحيات عالية إلى خادم لينكس، ما يرفع مستوى الخطر في بيئات الاستضافة التي تفعّل المحاكاة الافتراضية المتداخلة.
ما هي ثغرة زابسكيب في KVM ولماذا تهم مستخدمي لينكس؟
تظهر الثغرة الجديدة، المسجلة باسم CVE-2026-64561، داخل مكوّن KVM/x86 المسؤول عن إدارة الذاكرة الظلية أو Shadow MMU. هذه الآلية تُستخدم لترجمة ذاكرة الضيوف في سيناريوهات المحاكاة الافتراضية المتداخلة.
المشكلة لا تهدد كل الأنظمة بالدرجة نفسها، لكنها تصبح حساسة جداً عندما يسمح الخادم لضيف غير موثوق بالعمل كآلة L1 مع تفعيل nested virtualization. هنا يمكن للمهاجم، إذا حصل على صلاحيات نواة داخل الضيف، كسر العزل والوصول إلى المضيف نفسه.
كيف يمكن استغلال ثغرة زابسكيب للوصول إلى خادم لينكس؟
جوهر الخلل هو خطأ في ترتيب التحقق داخل مسار إدارة الذاكرة، ما قد يقود إلى حالة use-after-free. ببساطة، قد يواصل KVM معالجة خطأ صفحة باستخدام جذر ذاكرة تم إبطاله بالفعل أثناء الاسترجاع.
سلسلة الاستغلال باختصار
- المهاجم يحتاج إلى صلاحيات kernel داخل ضيف L1، وغالباً يعني ذلك root داخل الآلة الافتراضية.
- أثناء معالجة page fault، قد يستعيد KVM صفحات MMU ويُبطل الجذر النشط.
- المسار المتأثر لا يعيد التحقق من الجذر بعد الإبطال.
- ينتج عن ذلك صفحات فرعية مرتبطة بحالة غير صالحة، ثم أخطاء في القوائم الداخلية وكتابة بعد التحرير.
بحسب التفاصيل التقنية التي تابعها تيكبامين، فإن هذا التسلسل يمكن أن يتحول من خلل داخلي في الذاكرة إلى تنفيذ أوامر على المضيف بصلاحيات root، وهي أخطر نتيجة ممكنة تقريباً في خوادم KVM المعرضة للخطر.
ما الأنظمة المتأثرة بثغرة زابسكيب؟
الثغرة تستهدف بيئات KVM على لينكس عند تفعيل المحاكاة الافتراضية المتداخلة للضيوف غير الموثوقين. الاستغلال العملي المعروض استهدف AMD nested SVM/NPT، لكن أثر الخلل لا يقتصر على منصة واحدة فقط.
- المنصات المتأثرة: خوادم Linux التي تستخدم KVM/x86.
- الشرط الأساسي: nested virtualization مكشوفة لضيف غير موثوق.
- على Intel: يلزم كشف EPT page-walk length 4 و5 لضيف L1.
- على AMD: لا يوجد الشرط المكافئ نفسه، ما قد يسهل بعض السيناريوهات.
ومن المهم التوضيح أن QEMU ليس أصل المشكلة هنا، لأن الخلل موجود داخل KVM المدمج في النواة، وليس في طبقة المحاكاة الخاصة بـ QEMU.
كيف تحمي خادمك من ثغرة زابسكيب في KVM؟
الإصلاح الرسمي دُمج بالفعل في الشجرة الرئيسية، لذلك الخطوة الأهم الآن هي التحديث السريع إلى نواة مستقرة تتضمن التصحيح أو إلى حزمة من مزود النظام قامت بترحيل الإصلاح backport.
خطوات عملية للمسؤولين
- تحديث kernel أو حزم التوزيعة فوراً.
- تعطيل nested virtualization مؤقتاً إذا كانت مكشوفة لعملاء غير موثوقين.
- مراجعة صلاحيات الضيوف ومنع الوصول غير الضروري إلى مستوى root.
- اختبار بيئات الاستضافة المعزولة قبل إعادة تفعيل الإعدادات الحساسة.
في الوقت الحالي لا توجد مؤشرات علنية مؤكدة على استغلال واسع النطاق، لكن وجود نموذج إثبات عملي يرفع مستوى الاستعجال. لذلك ترى تيكبامين أن التعامل مع ثغرة زابسكيب يجب أن يكون أولوية فورية لكل من يدير خوادم KVM أو بنية سحابية تعتمد على لينكس.
