اكتشف الباحثون ثغرة في معالجات AMD Zen 2، والتي قد تسمح لممثل خبيث بسرقة البيانات الحساسة، مثل كلمات المرور ومفاتيح التشفير. في حين أن العديد من البيئات السحابية لديها أعباء عمل تعمل على وحدات المعالجة المركزية المتأثرة، فإننا نقدر أن Zenbleed ليس من المرجح أن يكون له تأثير في البيئات السحابية.
سنقوم بتحديث منشور المدونة هذا مع نشر المزيد من المعلومات.
CVE-2023-20593 هي ثغرة أمنية ناجمة عن التعامل غير السليم مع ملف vzeroupper التعليمات أثناء تنفيذ المضاربة، وهي تقنية شائعة لتحسين الأداء تستخدم في جميع المعالجات الحديثة. على عكس العديد من الثغرات الأمنية الأخرى في الأجهزة التي تعتمد على القنوات الجانبية (مثل Rowhammer وMeltdown وSpectre)، يعمل هذا الهجوم بشكل موثوق ويحقق نتائج فورية مع القليل من المتطلبات الأساسية، بخلاف أن المضيف يجب أن يستخدم معالج فئة AMD Zen 2.
استخدم الباحث عدادات التشويش والأداء لتحديد أحداث أجهزة معينة. وقد تحقق من صحة النتائج التي توصل إليها باستخدام نهج “تسلسل أوراكل”. وباستخدام تقنية “تسلسل أوراكل” قام الباحث بمقارنة تنفيذ برنامج تم إنشاؤه عشوائيا مع أوراكل المتسلسل الخاص به. كشفت هذه المقارنة عن تناقضات، مما أدى في النهاية إلى اكتشاف CVE-2023-20593 في وحدات المعالجة المركزية Zen 2.
سمح استغلال هذا الخلل للباحث بإطلاق استغلال محسّن والوصول إلى البيانات الحساسة من عمليات النظام المختلفة. حتى العمليات في الأجهزة الافتراضية وصناديق الحماية المعزولة والحاويات والبيئات الأخرى كانت عرضة لتسرب البيانات.
لقد ثبت أنه في الأنظمة الضعيفة، يمكنك قراءة ذاكرة العملية المميزة من عملية غير مميزة. وبالتالي تسمح هذه الثغرة الأمنية بقراءة محلية مميزة، مما يعني أنه يجب على المهاجم أولاً تنفيذ التعليمات البرمجية على النظام لاستغلالها بفعالية.
من الناحية النظرية، قد يتم استغلال هذه الثغرة الأمنية من قبل مهاجم لديه حق الوصول غير المميز إلى جهاز متأثر من أجل تصعيد امتيازاته أو الوصول إلى البيانات التي قد لا يتمتع بها.
بالإضافة إلى ذلك، قد يستغل مهاجم لديه أذونات تنفيذ تعليمات برمجية على إحدى الحاويات هذه الثغرة الأمنية للوصول إلى البيانات من حاويات أخرى تعمل على نفس العقدة. في البيئات الحاوية متعددة المستأجرين مثل K8s، قد يؤدي ذلك إلى وصول غير مصرح به بين المستأجرين.
نظرًا لأن هذين السيناريوهين يتطلبان أن يكون لدى المهاجم امتيازات وصول حالية وتنفيذ تعليمات برمجية محلية على جهاز متأثر، فمن المتوقع أن تكون معدلات التصحيح سريعة جدًا، كما أن موفري الخدمات السحابية لديهم إجراءات تخفيف لتقليل تأثير استغلال هذا النوع من الثغرات الأمنية، ونحن نصنف هذه الثغرة الأمنية على أنها منخفضة الخطورة في البيئات السحابية.
يؤثر الخلل على جميع وحدات المعالجة المركزية AMD المبنية على بنية Zen 2، بما في ذلك:
لاحظ أن هذا الخلل لا يعتمد على أي نظام تشغيل معين. تتأثر كافة أنظمة التشغيل.
في البيئات السحابية، نقدر أن الغالبية العظمى (إن لم يكن كلها) من مثيلات الأجهزة الافتراضية التي يحتمل أن تتأثر تعمل على “روما”، وهي وحدة معالجة مركزية مصممة لمراكز البيانات. في AWS، يتضمن ذلك أنواع المثيلات C5a وC5ad وG4ad وG5 EC2. في Azure، يتضمن ذلك الأجهزة الافتراضية HBv2 وDa_v3 وEa_v3. في GCP، يتضمن ذلك الأجهزة الافتراضية n2d-s2 (روما)، وn2d-s4 (روما)، وn2d-s8 (روما).
لقد نشر Google Cloud Platform نشرة أمنية تفيد أنهم قاموا بالفعل بتصحيح جميع المضيفين ضد هذه المشكلة. نشرت AWS إرشادات أمنية تفيد بأنها ستنشر التصحيح بمجرد اختباره (تحرير: قامت AWS منذ ذلك الحين بتحديث إرشاداتها، مع الإشارة إلى أنه تم تصحيح جميع الأجهزة المضيفة). في AWS، نظرًا لبنية نظام Nitro، فإن استغلال الثغرة الأمنية في مثيلات EC2 سيوفر للمهاجم امتيازات لنفس مثيل EC2 فقط. لم يصدر Azure وموفرو الخدمات السحابية الآخرون نشرات أمنية حتى الآن (اعتبارًا من وقت النشر).
بحسب الكشف الجدول الزمني, أصدرت AMD تصحيحات قبل تاريخ الحظر المتفق عليه، مما دفع الباحث إلى الكشف عن هذه المشكلة في وقت أبكر مما كان مخططًا له، مما أدى على الأرجح إلى تفاجأ شركاء AMD، مثل موفري الخدمات السحابية، في تخطيط التصحيح الخاص بهم (من المحتمل أن Google Cloud Platform كانت على علم بهذه المشكلة في وقت أبكر من الآخرين، حيث تم إجراء البحث ضمن Google Project Zero، وبالتالي كان لديها المزيد من الوقت للتحضير).
إذا تأثرت وحدة المعالجة المركزية الخاصة بك بـ Zenbleed، فمن المستحسن تطبيق تحديث الرمز الصغير الجديد من AMD أو الانتظار حتى يقوم بائع الكمبيوتر الخاص بك بدمج الإصلاح في ترقية BIOS المستقبلية. من الأفضل التعامل مع هذا الأمر بواسطة موفري الخدمة السحابية، ولكن هناك بعض خطوات التخفيف التي قد تكون ممكنة من داخل الأجهزة الافتراضية. لاحظ أن تطبيق تحديث الرمز الصغير من داخل جهاز افتراضي ليس له أي تأثير، حيث يجب تطبيقه من المضيف (في السحابة، هذا شيء لا يمكن إلا لمقدمي الخدمات السحابية القيام به، وليس عملائهم). وبالمثل، فإن تطبيق التخفيف “بت الدجاجة” (الموصوف في إعلان الثغرة الأمنية كحل بديل محتمل) ليس ممكنًا تقنيًا من داخل مثيل VM مستضاف على السحابة. إذا كنت تستخدم أيًا من أنواع مثيلات VM المذكورة أعلاه في البيئة السحابية الخاصة بك (باستثناء GCP)، فيجب عليك تحديد جميع هذه المثيلات والتأكد من تأمينها بطريقة أخرى حتى يعلن مقدمو خدمات الاتصالات عن تطبيق تحديثات الرمز الصغير على أنواع المثيلات ذات الصلة.
بالنسبة لجهاز Linux VM محدد، يمكنك اتباع هذه الخطوات للتحقق يدويًا مما إذا كان جهازك المضيف متأثرًا بـ Zenbleed:
أولاً، قم بتشغيل الأمر التالي للتحقق من طراز وحدة المعالجة المركزية الخاصة بمضيفك، ثم ابحث عبر الإنترنت لمعرفة ما إذا كان هذا النموذج يستخدم البنية الدقيقة Zen 2. إذا حدث ذلك، فانتقل إلى الخطوة التالية. وبخلاف ذلك، لن يتأثر جهازك بـ Zenbleed.
$ lscpu -J | grep 'Model name'
بعد ذلك، للتحقق مما إذا كان جهازك يعمل على أحدث إصدار من الرمز الصغير، وهو 0x0830107A (اعتبارًا من تاريخ النشر)، يمكنك تشغيل الأمر التالي.
$ grep 'microcode' /proc/cpuinfo
لاحظ أن بعض توزيعات Linux نشرت تفاصيل عن حزم تحديث الرمز الصغير وبالتالي قد يتم اكتشاف الثغرة الأمنية في الإصدارات الأقدم من هذه الحزم. ومع ذلك، يمكن اعتبار هذه نتائج إيجابية كاذبة على الأجهزة الافتراضية حيث يلزم تطبيق تصحيح الرمز الصغير من المضيف كما هو مذكور أعلاه.
يمكن لعملاء Wiz استخدام الاستعلام والاستشارات المعدة مسبقًا في مركز التهديد ويز للبحث عن الحالات الضعيفة في بيئتهم.
