تسمح الثغرة الأمنية في KVM بتنفيذ التعليمات البرمجية خارج نظام الضيف على معالجات AMD

كشف باحثون من فريق Google Project Zero النقاب قبل أيام قليلة في منشور مدونة حددت ثغرة أمنية (CVE-2021-29657) في برنامج Hypervisor KVM (برنامج Hypervisor مفتوح المصدر قائم على نظام Linux يدعم المحاكاة الافتراضية المسرَّعة للأجهزة على x86 و ARM و PowerPC و S / 390) يسمح لك بتجنب عزل نظام الضيف وتشغيل الكود الخاص بك على جانب البيئة المضيفة.

يذكر المنشور أن المشكلة بيانات من Linux kernel 5.10-rc1 إلى v5.12-rc6 ، هذا هو ، يغطي فقط النواة 5.10 و 5.11 (معظم الفروع المستقرة للتوزيعات لم تتأثر بالمشكلة). المشكلة موجودة في آلية nested_svm_vmrun ، التي تم تنفيذها باستخدام امتداد AMD SVM (آلة افتراضية آمنة) وتسمح بالتشغيل المتداخل لأنظمة الضيف.

في منشور المدونة هذا ، أصف ثغرة أمنية في كود KVM الخاص بـ AMD وناقش كيف يمكن أن يتحول هذا الخطأ إلى هروب كامل للجهاز الظاهري. وبقدر ما أعلم ، هذه هي أول عملية كتابة عامة لكسر KVM من ضيف إلى مضيف لا يعتمد على الأخطاء في مكونات مساحة المستخدم مثل QEMU.

تم تعيين الخطأ الذي تمت مناقشته CVE-2021-29657 ، ويؤثر على إصدارات kernel v5.10-rc1 إلى v5.12-rc6 ، وتم تصحيحه في أواخر مارس 2021. نظرًا لأن الخطأ أصبح قابلاً للاستغلال فقط في الإصدار 5.10 وتم اكتشافه بعد حوالي 5 أشهر ، يجب ألا تتأثر معظم عمليات نشر KVM الحقيقية ما زلت أعتقد أن المشكلة هي دراسة حالة مثيرة للاهتمام في العمل المطلوب لبناء هروب ثابت من ضيف إلى مضيف ضد KVM وآمل أن تتمكن هذه المقالة من إثبات أن التسويات عبر برنامج Hypervisor ليست مجرد مشاكل نظرية.

يذكر الباحثون أنه من أجل التنفيذ الصحيح لهذه الوظيفة ، يجب على برنامج Hypervisor اعتراض جميع تعليمات SVM تعمل على أنظمة الضيف ، محاكاة سلوكه ومزامنة الحالة مع الأجهزة ، وهي مهمة صعبة للغاية.

بعد تحليل تطبيق KVM المقترح ، قام الباحثونواجه s خطأ منطقيًا يسمح بمحتوى MSR (تسجيل خاص بالطراز) للمضيف تتأثر بنظام الضيف، والتي يمكن استخدامها لتنفيذ التعليمات البرمجية على مستوى المضيف.

على وجه الخصوص ، يؤدي تشغيل عملية VMRUN من ضيف المستوى المتداخل الثاني (تم إطلاق L2 من ضيف آخر) إلى استدعاء ثانٍ إلى nested_svm_vmrun وإفساد بنية svm-> nested.hsave ، والتي يتم تراكبها ببيانات من vmcb من نظام الضيف L2 .

نتيجة لذلك ، ينشأ موقف حيث يمكن على مستوى الضيف L2 تحرير الذاكرة في بنية svm-> nested.msrpm ، التي تخزن بت MSR ، على الرغم من استمرار استخدامها ، والوصول إلى MSR الخاص بالمضيف البيئة.

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

بالإضافة إلى ذلك ، يمكن لـ KVM إلغاء تحميل معظم الأعمال المتعلقة بمحاكاة الجهاز لمكون مساحة المستخدم.

تكمن المشكلة في الكود المستخدم في الأنظمة التي تحتوي على معالجات AMD (وحدة kvm-amd.ko) ولا تظهر في معالجات Intel.

 خارج جهازين حساسين للأداء يتعاملان مع معالجة المقاطعة ، يمكن نشر كل التعليمات البرمجية ذات المستوى المنخفض المعقدة لتوفير قرص افتراضي أو شبكة أو وصول GPU في مساحة المستخدم.  

بالإضافة إلى وصف الباحثين للمشكلة لقد أعدوا أيضًا نموذجًا أوليًا عمليًا للاستغلال الذي يسمح بتشغيل shell root من بيئة الضيف في بيئة مضيفة على نظام به معالج AMD Epyc 7351P ونواة Linux 5.10.

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

أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها حول الملاحظة ، يمكنك التحقق من التفاصيل في الرابط التالي.


كن أول من يعلق

اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

*

*

  1. المسؤول عن البيانات: ميغيل أنخيل جاتون
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.