في كل مرة تُنشر فيها “مكافحة” لهجوم سبكتر v2، يفترض الدفاع أن المسار الحرج داخل النواة لا يُقاطع. لكن فريقًا بحثيًا من معهد ماساتشوستس للتقنية (MIT) يقلب هذه الفرضية: حتى البرامج غير المميزة على لينكس قد تستطيع توقيت مقاطعة عتادية في لحظة دقيقة لإعادة “تسميم” سجل التنبؤات الفرعية بعد تنفيذ جزء من الحماية—ما يفتح الباب لتسريب معلومات من الذاكرة.
البحث، الذي أطلق عليه الباحثان اسم حقن المقاطعات ( INTERRUPT INJECTION )، يُظهر عمليًا كيف يمكن لهجوم قائم على توقيت المقاطعات أن يتسلل عبر نافذة صغيرة بين “تحييد” حالة التنبؤات وبين “استخدامها” داخل مسار العودة الآمن (Safe-RET). ورغم أن النافذة تبدو ضيقة للغاية—تعادل بضع تعليمات على بعض المعالجات—فإن وجود مشاركة موارد على الأنظمة متعددة المستخدمين يجعل احتمال الاستغلال أكثر واقعية.
ما الذي تعنيه “النافذة الزمنية” في هجمات سبكتر v2؟
لفهم خطورة حقن المقاطعات، نحتاج إلى تبسيط مفهومين:
التنبؤات الفرعية: المعالج يستخدم تنبؤات لتسريع التنفيذ. في هجمات سبكتر، تُستغل هذه التنبؤات لإقناع النظام بتنفيذ مسار “مضلّل” ثم تسريب ما تمّت ملاحظته عبر قنوات جانبية.
تحييد الحالة ثم استخدامها: في الاستراتيجيات المضادة لسبكتر v2، تقوم النواة بتحييد أو تنظيف حالة التنبؤات قبل الدخول أو قبل العودة من إجراءات حساسة. الفكرة الأساسية هي منع أن تكون “تدريبات” المهاجم السابقة قادرة على توجيه التنفيذ داخل النواة.
لكن الباحثين يشيرون إلى نمط جديد من السباق يشبه TOCTOU في البرمجيات: يسمونه الزمن بين التحييد والاستخدام ( Time-of-Neutralization to Time-of-Use أو TONTOU ). المقصود أن المقاطعات قد تدخل في منتصف المسار الدفاعي، فتُعيد تشكيل سياق التنفيذ بدلًا من السماح للحماية أن تظل “متصلة” حتى لحظة الاستخدام.
تفاصيل الاختراق كما وردت في البحث: من دون امتيازات
اللافت في الدراسة هو أن المهاجم لا يحتاج إلى صلاحيات إدارية ولا حتى امتيازات نواة. يكفي تنفيذ كود محلي غير مميز على نظام لينكس يعمل على معالجات متأثرة—خصوصًا في بيئات المشاركة مثل الخوادم متعددة المستخدمين أو السحابة.
على منصة AMD Zen 2 وفق الدراسة (لينكس 6.14 مع تفعيل “كل” تخفيفات Spectre v2 الافتراضية)، حقق الباحثان تسريبًا يصل إلى 5.47 بايت في الثانية بدقة تقارب 91.97%. والأهم عمليًا: تمكنوا في 5 من 10 محاولات من تحديد وقراءة الملف /etc/shadow—وهو ملف شديد الحساسية يخزن تجزئات كلمات المرور.
هذا النوع من النتائج لا يعني أن كل نظام متأثر سيُستغل تلقائيًا، لكنه يثبت أن “الافتراض الدفاعي” الخاص بعدم وجود كود عدائي بين التحييد والاستخدام ليس مضمونًا عندما تكون المقاطعات قابلة للجدولة بدقة عالية من مساحة المستخدم.
لماذا المقاطعات بالذات؟ وما علاقة Safe-RET؟
المعالجة المضادة لسبكتر v2 في النواة تعتمد على تنظيف/تحييد حالة التنبؤ قبل لحظة حاسمة. في حالة Safe-RET، تُجرى خطوات لتأمين مسار العودة (RET) ومنع أن تؤدي تدريبات المهاجم إلى توجيه التنفيذ داخل النواة.
لكن الباحثين يوضحون أن هذه الحمايات—في جوهرها—تتعامل مع سيناريو يفترض أن المعالج لا ينفّذ مقاطع غير متوقعة بين “التحييد” و”الاستخدام”. في العالم الحقيقي، حدث المقاطعة قد يحدث في أي وقت تقريبًا، وLinux يسمح للمستخدمين بجدولة أحداث على مستوى زمني دقيق.
على Zen 2، وصفت الدراسة أن نافذة التوقيت الضيقة لا تتجاوز تعليمتين (تعادل 6 بايت). ولزيادة احتمال سقوط المقاطعة داخل النافذة، استخدم الباحثان تقنيات مثل:
إخلاء تلك البايتات من ذاكرات التخزين المؤقت (L1 وL2) عبر الاستفادة من التوازي في الخيطين (hyperthreading) لإبطاء المسار.
اختيار نوع استدعاء النظام (write) لضمان قدر من التحكم في السجلات، ما يساعد على تفعيل “قطعة” تدريب داخل مسار المقاطعة نفسها.
وفق الدراسة، تصل فرص وقوع المقاطعة داخل النافذة إلى 5% إلى 12%، وقد تنخفض إلى حوالي 2%** عند ضبط السجلات ضمن سيطرة المهاجم. ومع ذلك، حتى هذه النسبة تكفي لتحقيق تسريب عملي عندما تتوافر “قناة إفصاح” داخل النواة.
حلقة الإفصاح: Inception وملحوظة عن قابلية التوسع
جزء الحيلة لا يتوقف عند كسر التسلسل الدفاعي. بمجرد أن تحدث المقاطعة داخل النافذة، يتحول معالج المقاطعة ذاته إلى “قطعة تدريب” (training gadget) تُستخدم لتعبئة Return Stack Buffer بهدف توجيه التنفيذ بشكل يتيح التسريب. وتذكر الدراسة استخدام Inception ( CVE-2023-20569 )—وهو خلل سابق متعلق بحماية saferet—لتسهيل تعبئة هذا المخزن بعناوين يحددها المهاجم.
من حيث النتائج التفصيلية، ظهرت “أخطاء تنبؤ” داخل كود النواة على 3 من 4 منصات اختبرها الباحثون، بنِسَب نجاح منخفضة لكنها قابلة للتجميع إحصائيًا:
Zen 2: 0.75%
Intel Arrow Lake: 0.22%
Cascade Lake Refresh: 0.037%
Zen 4: لم تُسجل أخطاء في الاختبار المذكور
في المقابل، لم يُظهر الباحثون هجومًا “من النهاية إلى النهاية” على Intel في هذه التجارب، ويرجع ذلك—بحسب تفسيرهم—إلى الحاجة لوجود “قطعة إفصاح” قابلة للاستخدام ضمن النواة، وهو افتراض قد يتغير بتغيرات النظام/التهيئة/النسخ.
ومع ذلك، لا يعتبر الفريق عدم ظهور تسريب على Intel دليلًا على عدم القابلية للاستغلال. فهم يرون أن وجود شرط “التنبؤ الخاطئ” لا يكفي وحده لكنه ضروري، وأن الجمع بين بدئهم (Interrupt Injection) وأعمال سابقة حول وجود قنوات إفصاح في النواة قد يجعل هجومًا كاملًا ممكنًا أيضًا على معالجات Intel.
ماذا فعلت الشركات؟ AMD أصدرت تحديثًا… وIntel اختلفت في تقدير الحاجة
وفق تسلسل الإفصاح، قام الباحثان بمشاركة التفاصيل مع AMD وIntel في 5 فبراير. وبحسب ما ورد:
AMD قالت إنها تخطط لإصدار رقعة على مستوى النواة.
MIT أفاد بأن رقعة قد تم شحنها لاحقًا ووصلت إلى تحديثات نظام التشغيل بشكل اعتيادي.
على مستوى التطوير في نواة لينكس، يشير البحث إلى التزام إصلاحي بعنوان: “x86/bugs: Make Safe-RET robust against interrupt injection” بتاريخ 2 يونيو، من كتابة Borislav Petkov وبمشاركة/تطوير مع David Kaplan (كلاهما مهندسان في AMD). الفكرة الجوهرية في الرقعة هي:
تجنب تنفيذ تعليمات RET بعد عودة المقاطعة في سيناريو قد يعيد فتح نافذة غير محمية.
كما أصدرت AMD نشرة رسمية تحمل الرقم AMD-SB-7061 بعنوان Safe RET Interrupt Vulnerability بتاريخ 6 أغسطس. وتذكر النشرة أن المهاجم الذي يشغل كودًا على نظام متأثر قد يحقن مقاطعة في لحظة دقيقة لتعطيل Safe-RET، ما قد يضعف الحماية ويؤدي إلى إفصاح معلومات. وتربط AMD المشكلة بتنفيذ Linux الخاص بـ Safe-RET.
في المقابل، ورد أن Intel لا ترى أن تخفيفًا إضافيًا ضروريًا، وأن قابلية الاستغلال تعتمد على عوامل متعددة. وقد راجعت التقارير إرشادات Intel ( INTEL-SA-00598 ) ولم يتضح فيها ذكر للمقاطعات بشكل صريح.
ماذا يعني ذلك لمسؤولي الأمن؟ اختبار الأثر ليس دائمًا مباشرًا
واحدة من نقاط القلق العملية في هذه القضية هي أن تفاصيل الإصلاح قد لا تكون مرتبطة بـ رقم CVE أو باسم إصدار نواة واضح في بعض الإعلانات. ووفق ما ورد، لا تُشير النشرة إلى مرجع مباشر للـ commit، ما يعني أن مسؤول النظام قد يحتاج إلى مطابقة موضوع التصحيح مع ما تم تضمينه فعليًا في نسخة النواة لديه.
على لينكس، يمكن التحقق من حالة SRSO عبر الملف: /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow. لكن ملاحظة مهمة: الوثائق التي تحدد قيم هذا الملف لم تُشر—بحسب متابعة التقارير—إلى دور حقن المقاطعات، ما يجعل الاعتماد عليه وحده غير كافٍ لتقييم المخاطر.
لذلك، نهج “الدفاع القائم على التحديث” يبقى الأساس، مع إضافة تدقيق تقني في نسخ النواة والإعدادات ذات الصلة.
كيف تتصل هذه الواقعة باتجاهات أوسع في الأمن السيبراني؟
قضية حقن المقاطعات ليست مجرد ثغرة جديدة؛ إنها مؤشر على تحول أوسع في هندسة الدفاع ضد الهجمات الميكرو-معمارية (microarchitectural). لسنوات، ركزت الاستجابة لسبكتر v2 على تنظيف الحالة قبل الدخول/العودة. لكن هذا النهج يواجه تحديًا متكررًا: الافتراضات حول “الزمن غير القابل للتدخل” داخل النواة قد تنهار أمام الأحداث غير المتوقعة مثل المقاطعات، وجدولة المهام، وسلوك المعالجات الحديثة.
هذا يتقاطع أيضًا مع مبدأ “تقليل السطح” و”التقليل من الامتيازات” و”العزل” كما توصي أطر مثل ممارسات NIST العامة لتقليل المخاطر، ومع مبادئ OWASP في تقليل أثر الفشل. لكن هنا، الفشل ليس فقط في منطق برمجي؛ بل في تفاعل البرمجيات مع سلوك المعالج.
ومن زاوية إدارة المخاطر، يبرز أيضًا عامل “البيئات المشتركة”: حتى لو كان الهجوم يتطلب “محليًا” فقط، فإن الأنظمة التي تستضيف مستخدمين/حاويات متعددة على نفس المضيف تصبح أكثر عرضة لسيناريوهات الاستغلال—خصوصًا عندما تتوفر قنوات إفصاح داخل النواة.
توصيات عملية مختصرة
تحديث نواة لينكس إلى إصدارات تتضمن الرقعة التي تجعل Safe-RET أكثر متانة ضد حقن المقاطعات.
تدقيق نسخ النواة مقابل سجل التغييرات (changelogs) أو البحث عن موضوع الإصلاح “Make Safe-RET robust against interrupt injection”.
مراجعة بيئات المشاركة (خوادم متعددة المستخدمين/سحابة/حاويات) وتقييم ما إذا كانت عزل العمليات كافيًا لتقليل احتمالات “التنافس على التوقيت”.
الاستمرار في اختبار الحماية بدل الاعتماد على مؤشر واحد مثل حالة SRSO فقط.
كيف يمكن للمؤسسات قياس جاهزيتها أمام الهجمات القائمة على التوقيت؟
هذا النوع من الثغرات يطرح سؤالًا يفوق “هل لدينا تحديث؟” إلى “هل نفهم افتراضات الدفاع التي بُنيت عليها الحماية؟”.
السؤال للمناقشة: إذا كانت مقاطعة عتادية واحدة في لحظة خاطئة قد تُعيد فتح نافذة دفاعية، فهل تعتمد سياساتكم اليوم على مؤشرات سطحية (مثل تفعيل تخفيفات معينة) أم أنها تشمل تحققًا أعمق من مسارات التنفيذ في النواة—خصوصًا في الأنظمة المشتركة؟
روابط للمزيد:
تنبيه للنشر: إذا رغبت، أستطيع أيضًا إعداد نسخة “تقرير تنفيذي” من صفحة واحدة موجهة للإدارة، أو قائمة تحقق تقنية لمسؤولي لينكس لتحديد مدى احتواء التصحيح في نسخهم الحالية.
Leave a Reply