تم الكشف مؤخراً عن ثغرة أمنية تُعرّض خوادم الحوسبة السحابية للخطر. تسمح هذه الثغرة للمهاجمين بالسيطرة الكاملة على الجهاز الفعلي ، وهو سيناريو كارثي لمزودي البنية التحتية السحابية.
تُعدّ ثغرة Zapscape، المسجلة تحت المعرّف CVE-2026-64561، ثغرة أمنية خطيرة في مُشرف الأجهزة الافتراضية KVM لنظام Linux، تُعرّض العديد من المنصات لمخاطر قد تقع فيها دون قصد عند تفعيلها للتقنية الافتراضية المتداخلة. تسمح هذه الثغرة للمهاجم الذي يمتلك صلاحيات نواة النظام في جهاز افتراضي (الطبقة 1) بتنفيذ تعليمات برمجية بصلاحيات الجذر على النظام المضيف (الطبقة 0)، مما يُخلّ بعزل البيئات الافتراضية.
يُعتبر برنامج Zapscape تهديدًا عالي التأثير، فهو لا يسهل الهروب من الجهاز الظاهري فحسب، بل يفتح أيضًا مسارًا محليًا لتصعيد الامتيازات لمستخدمي المضيف الذين لديهم أذونات الكتابة على جهاز /dev/kvm.
على الرغم من أن منظمات مثل Red Hat قد صنفت الثغرة الأمنية بدرجة CVSS 7.0 مع التركيز على عدم الاستقرار وحجب الخدمة، إلا أن إثبات المفهوم العام (PoC) يوضح نطاقًا أكثر تدميرًا: إنشاء ملف عشوائي مباشرة في جذر المضيف.
فوضى في وحدة إدارة الذاكرة
تُخفى آلية عمل Zapscape داخل وحدة إدارة الذاكرة (MMU) الخاصة بـ KVM ، وكيفية تعامل برنامج إدارة الأجهزة الافتراضية (Hypervisor) مع جداول الصفحات عندما يعمل نظام تشغيل ضيف (L1) كبرنامج إدارة أجهزة افتراضية لنظام تشغيل ضيف فرعي آخر (L2). تكمن المشكلة في خطأ في الترتيب المنطقي أثناء معالجة أخطاء الصفحات. في مسارات كود النواة، تم تنفيذ فحص "الجذر القديم" قبل دالة استرجاع الصفحة، بدلاً من تنفيذه بعدها.
يؤدي هذا التسلسل غير الصحيح إلى سيناريو "استخدام بعد التحرير" الكلاسيكي . أثناء عملية الاسترداد، يمكن لـ KVM إزالة الجذر الذي يستخدمه ووضع علامة عليه بأنه غير صالح. ومع ذلك، نظرًا لأن فحص السلامة قد تم تشغيله بالفعل، يستمر النظام في إنشاء عمليات الربط تحت جذر لم يعد صالحًا. ومن المثير للاهتمام أن مشكلة الفرز هذه موجودة في الكود منذ عام 2008، لكنها أصبحت حرجة وقابلة للاستغلال بعد إصدار نواة لينكس 5.9 في يوليو 2020 ، عندما تم تقديم توجيه توقف النظام ببساطة عن فرضه.
المتطلبات والقيود
لكي يكون Zapscape قابلاً للاستغلال، يجب أن تستوفي البيئة متطلبات محددة للغاية. أولاً، يجب تفعيل المحاكاة الافتراضية المتداخلة في وحدة KVM، وهو تكوين يسمح ببنية ثلاثية الطبقات (L0، L1، وL2). يحتاج المهاجم إلى بدء الهجوم من طبقة L1 ، الأمر الذي يتطلب صلاحيات الجذر على تلك الآلة الافتراضية. ومن هناك، يتلاعب المهاجم بأوضاع الذاكرة بينما يجبر نشاط الضيف الفرعي L2 المضيف L0 على بدء استرجاع صفحات الحصص، مما يتسبب في تلف الذاكرة.
على مستوى المكونات المادية، تختلف الشروط باختلاف الشركة المصنعة. في أنظمة AMD التي تستخدم جداول الصفحات المتداخلة ( SVM )، تكون الثغرة الأمنية أبسط ولا تتطلب أي ميزات إضافية. في المقابل، في معالجات Intel، يتطلب السيناريو أن يكون لدى نظام التشغيل الضيف L1 إمكانيات الوصول إلى صفحات EPT من أربعة وخمسة مستويات . هذا يحد من إمكانية استغلال الثغرة في معالجات Intel إلى البنى الأحدث، وتحديدًا من عائلة Ice Lake-SP فصاعدًا.
تجدر الإشارة إلى أنه على الرغم من أن إثبات المفهوم العام قد تمكن من الوصول إلى المضيف في بيئات خاضعة للرقابة، فقد أفاد باحثو الأمن أنه في بعض النوى المعاد تجميعها، فإن الاستغلال ببساطة يؤدي إلى تعطل الجهاز الظاهري للمهاجم، مما يعمل كحجب للخدمة بدلاً من الهروب الكامل.
التخفيف والتصحيحات والاستراتيجيات
وصل الحل النهائي لثغرة Zapscape إلى مستودعات لينكس في يوليو الماضي عبر رقعة تصحيحية تُعدّل ترتيب التحقق. ينقل هذا الإصلاح فحص الجذر القديم ليحدث بعد تخصيص صفحة وحدة إدارة الذاكرة (MMU)، مما يضمن عدم قيام برنامج إدارة الأجهزة الافتراضية (Hypervisor) بإنشاء عمليات ربط نشطة تحت جذر محذوف. وقد تم تطبيق هذه الإصلاحات بالفعل في فروع النواة المستقرة، ويجري توزيعها على نطاق واسع من قِبل مختلف توزيعات لينكس.
بالنسبة للمسؤولين الذين لا يستطيعون الترقية فورًا، توجد حلول مؤقتة فعّالة للغاية. يتمثل الإجراء ذو الأولوية في تعطيل المحاكاة الافتراضية المتداخلة على جميع الخوادم التي لا تتطلبها بشكل صارم، وذلك بتمرير المعامل `nested=0` إلى وحدات `kvm_amd` أو `kvm_intel` في ملفات تكوين modprobe. يتطلب هذا الإجراء إعادة تحميل الوحدة، مما يعني إيقاف أي أجهزة افتراضية نشطة.
وأخيرًا، إذا كنت مهتمًا بمعرفة المزيد، يمكنك العثور على التفاصيل في الرابط التالي.