ثغرة Januscape: هروب KVM ضار بـ Intel و AMD منذ 16 عاماً

مقدمة تحليلية

في 19 يونيو 2026، كشف الباحث Hyunwoo Kim النقاب عن ثغرة أمنية حرجة تحمل المعرف CVE-2026-53359، والمعروفة باسم Januscape، بعد 16 عاماً من بقائها دون اكتشاف في برنامج KVM (Kernel-based Virtual Machine) الخاص بنظام Linux. تسمح هذه الثغرة، وهي من نوع use-after-free، لآلة افتراضية ضيفة (guest VM) بالهروب إلى المضيف (host) وتنفيذ تعليمات برمجية عليه، مما يهدد استقرار وأمن البنى التحتية السحابية التي تعتمد على KVM. وقد استُخدمت الثغرة بالفعل كجزء من برنامج Google kvmCTF للمكافآت، الذي يقدم ما يصل إلى 250,000 دولار لاكتشاف مثل هذه العيوب الخطيرة.

الخلل موجود في رمز shadow MMU الذي تستخدمه KVM عبر معالجات Intel و AMD x86. إنه يؤثر على القدرة الأساسية لـ KVM على إدارة ذاكرة الآلات الافتراضية بأمان. هذه ليست مجرد مشكلة نظرية؛ فإثبات المفهوم (PoC) العام يسبب تعطل المضيف (panic)، بينما يدعي الباحث أن استغلالاً منفصلاً غير منشور يمكنه تحقيق تنفيذ كامل للتعليمات البرمجية على المضيف. تمثل Januscape، حسب علم الباحث، أول ثغرة هروب من الضيف إلى المضيف قابلة للتطبيق على كلا النوعين من المعالجات، مما يبرز اتساع نطاق تأثيرها والتهديد الذي تشكله.

التحليل التقني

تكمن المشكلة في طريقة إدارة KVM لذاكرة الآلات الافتراضية. لتشغيل آلة افتراضية، تحتفظ KVM بمجموعتها الخاصة من جداول الصفحات التي تعكس تخطيط ذاكرة الضيف. عندما تحتاج KVM إلى إحدى صفحات التتبع هذه، فإنها تبحث عن صفحة موجودة لإعادة استخدامها. هنا تكمن المشكلة: كانت KVM تطابق هذه الصفحات بناءً على عنوان الذاكرة فقط، وتتجاهل نوع صفحة التتبع التي كانت تستخدمها. يمكن لنوعين مختلفين من صفحات التتبع أن يشغلا نفس العنوان ولكن يؤديان وظائف مختلفة تمامًا، مما يؤدي إلى إعادة استخدام KVM للنوع الخاطئ.

هذا الخلط يفسد سجلات KVM الداخلية حول أي صفحة تنتمي إلى أين. بمجرد أن تكون هذه السجلات خاطئة، يصبح النظام عرضة للهجوم. في معظم الحالات، يلاحظ Kernel هذا الخطأ ويغلق نفسه لتجنب المزيد من الضرر، وهذا ما يسببه العرض العام للثغرة: يمكن للضيف أن يسقط المضيف بأكمله، آخذًا معه كل الآلات الافتراضية الأخرى على نفس الجهاز. الحالة الأسوأ والأندر تحدث عندما يتم تسليم صفحة التتبع المحررة لاستخدام آخر قبل أن ينظف Kernel بقاياها. عندئذ، تقوم عملية التنظيف بالكتابة في ذاكرة لم تعد تملكها. يتحكم المهاجم فقط في مكان هبوط هذه الكتابة، وليس ما يُكتب، لكن حتى هذه السيطرة المحدودة يمكن استغلالها لتشغيل تعليمات برمجية على المضيف.

الثغرة موجودة منذ commit 2032a93d66fa في أغسطس 2010 (حقبة Kernel 2.6.36) وتم إصلاحها بواسطة commit 81ccda30b4e8، والذي دُمج في mainline في 19 يونيو 2026. يتطلب الهجوم من جانب الضيف أمرين: صلاحيات الجذر (root) داخل الآلة الافتراضية، وهو شرط شائع في مثيلات السحابة المؤجرة، وتفعيل المحاكاة الافتراضية المتداخلة (nested virtualization) من جانب المضيف. حتى على المضيفين الذين يقومون بتشغيل EPT أو NPT للأجهزة افتراضياً، فإن المحاكاة الافتراضية المتداخلة تجبر KVM على العودة إلى shadow MMU القديم، وهو المكان الذي تكمن فيه الثغرة. لا يتطلب الاستغلال أي تعاون من QEMU أو أي مدير آلات افتراضية في مساحة المستخدمين؛ إنه خلل في KVM داخل Kernel بحت.

السياق وتأثير السوق

تضع ثغرة Januscape نفسها في سياق مقلق لسلسلة من العيوب المكتشفة مؤخرًا في Kernel Linux. إنها الثالثة للباحث Hyunwoo Kim في شهرين فقط. في مايو 2026، كشف عن Dirty Frag (CVE-2026-43284 / CVE-2026-43500)، وهي سلسلة ثغرات كتابة في ذاكرة التخزين المؤقت للصفحات تؤدي إلى صلاحيات الجذر على معظم التوزيعات الرئيسية. في يونيو، نشر ITScape (CVE-2026-46316)، وهو أول هروب مثبت علنًا من الضيف إلى المضيف على KVM/arm64. تضاف Januscape الآن إلى جانب x86. هذا المعدل من الاكتشافات يسلط الضوء على عمق المشكلات الأمنية الكامنة في البنية التحتية الأساسية.

• Januscape (x86) مقابل ITScape (ARM64): بينما تعالج ITScape هروب KVM على معالجات ARM64، تركز Januscape على بنى x86 الأكثر انتشاراً، مما يجعلها ذات تأثير أوسع على مراكز البيانات السحابية الحالية. تشترك الثغرتان في كونهما هروباً من الضيف إلى المضيف ولكن من خلال آليات مختلفة تمامًا.
• KVM غير المحدث مقابل KVM المحدث: الأنظمة التي لم يتم تحديثها تحمل خطرًا مباشرًا وشاملاً لتعطل المضيف أو الاستيلاء الكامل عليه، مما يجعلها فريسة سهلة. تضمن الأنظمة المحدثة الحماية ضد هذا الاستغلال المحدد، مما يجعل التحديث ضرورة قصوى.
• المضيفون الذين يسمحون بالمحاكاة الافتراضية المتداخلة مقابل الذين لا يسمحون: البيئات التي تسمح بالـ nested virtualization للضيوف غير الموثوق بهم هي الأكثر عرضة للخطر. تعطيل هذه الميزة يزيل مسار الهجوم المباشر، ويوفر تخفيفًا مؤقتًا حاسمًا.
• اكتشاف Hyunwoo Kim مقابل اكتشافات أخرى: تُظهر اكتشافات Kim المتسلسلة فهماً عميقاً لأوجه القصور في Kernel، مما يرفع معيار البحث الأمني ويدفع بضرورة إعادة تقييم شاملة للتعليمات البرمجية القديمة.

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

رؤية Glitch4Techs

ثغرة Januscape ليست مجرد خلل برمجي؛ إنها شهادة دامغة على الحاجة الملحة لإعادة التقييم الجذري لأمن البنى التحتية الأساسية. بقاء ثغرة بهذا الحجم لمدة 16 عاماً في مكون حيوي مثل KVM أمر لا يغتفر. يجب على أي مشغل لمضيف KVM x86 يقبل ضيوفًا متعددين ولديه المحاكاة الافتراضية المتداخلة أن يعتبر هذا التحديث أولوية قصوى. لا تنتظر الحصول على درجة CVSS من NVD؛ فقد قامت SUSE بتقييمها 8.8 (v3.1) / 9.3 (v4.0) بالفعل، مما يؤكد خطورتها القصوى.

تحديث Kernel الخاص بك إلى الإصدارات المستقرة التي تحمل التصحيح (مثل 7.1.3، 6.18.38، 6.12.95، 6.6.144، 6.1.177، 5.15.211، 5.10.260، التي شحنت في 4 يوليو 2026) هو الخطوة الأولى والوحيدة الفعالة. إذا كان التحديث الفوري غير ممكن، فإن تعطيل المحاكاة الافتراضية المتداخلة (kvm_intel.nested=0 أو kvm_amd.nested=0) هو إجراء تخفيفي إلزامي لإزالة مسار الهجوم على الضيوف غير الموثوق بهم. لا يوجد مكان هنا للتسويف أو البحث عن حلول بديلة معقدة. هذه الثغرة تعرض البيانات الحساسة والبنى التحتية بأكملها للخطر المباشر، والتقاعس ليس خيارًا.