DDRop: هجوم بـ159 دولارًا يجعل الخادم يصدّق ذاكرة قديمة ويكسر حماية TDX وSEV-SNP
تخيل أن المعالج كتب قيمة جديدة إلى الذاكرة، ثم عاد بعد لحظات ليقرأها. كل شيء يبدو طبيعيًا، لكن القيمة الجديدة لم تصل أصلًا، والذاكرة ما زالت تحتفظ بالنسخة القديمة.
هنا تبدأ فكرة DDRop. هجوم عتادي جديد يستهدف تقنيات الحوسبة السرية لدى Intel وAMD، ليس بكسر التشفير، بل بمنع بعض عمليات الكتابة إلى ذاكرة DDR5 من الوصول بصمت.
المعالج يقرأ بعدها البيانات القديمة المشفرة ويقبلها كأنها أحدث نسخة. محرك التشفير لا يرى بيانات تالفة، لذلك لا يكتشف أن شيئًا غير طبيعي حدث.
المشكلة ليست أن البيانات غير مشفرة. المشكلة أن النظام يستطيع التأكد من صحة التشفير، لكنه لا يستطيع دائمًا التأكد أن القيمة التي يقرأها هي أحدث قيمة كُتبت.
لوحة DDRop الاعتراضية التي توضع بين المعالج ووحدة ذاكرة DDR5.
#قبل كل شيء، ما الذي يحتاجه المهاجم؟
DDRop ليس هجومًا عن بعد، ولا يمكن تنفيذه بمجرد إرسال حزمة شبكة إلى خادم سحابي. المهاجم يحتاج أصلًا إلى صلاحيات برمجية مرتفعة على الخادم، مع وصول مادي قصير يسمح له بتركيب قطعة عتادية بين المعالج ووحدة الذاكرة.
هذه القطعة تسمى Interposer، وهي لوحة صغيرة تمر عبرها إشارات الذاكرة. بعد تركيبها يستطيع المهاجم التحكم بالهجوم برمجيًا دون الحاجة إلى البقاء بجانب الجهاز.
بحسب الباحثين، تكلفة المكونات اللازمة لبناء النظام الكامل تبلغ قرابة 159 دولارًا عند الشراء بكميات مناسبة. الرقم لا يشمل تكلفة البحث والتطوير أو التجميع.
وهذا بالضبط ما يجعل البحث مهمًا. نحن لا نتحدث عن مختبر يحتاج معدات بمئات آلاف الدولارات، بل عن نموذج يمكن تركيبه خلال دقائق ويعمل مع DDR5 بسرعتها الأصلية.
#لماذا الحوسبة السرية مهمة أصلًا؟
تقنيات مثل Intel TDX وIntel Scalable SGX وAMD SEV-SNP صممت لحماية البيانات أثناء استخدامها داخل الخادم. الفكرة أن مالك البنية التحتية نفسه لا يفترض أن يكون قادرًا على قراءة ذاكرة الحمل المحمي بسهولة.
الذاكرة تُشفّر بواسطة المعالج قبل وصول البيانات إلى DRAM. لذلك إذا راقب شخص ناقل الذاكرة أو قرأ محتويات الشرائح مباشرة، فمن المفترض أن يرى بيانات مشفرة لا يمكنه الاستفادة منها.
هذا النموذج مهم خصوصًا في البيئات السحابية. العميل يريد تشغيل حمل حساس على خادم لا يملكه، لكنه لا يريد أن يصبح مشغل السحابة أو الـ Hypervisor نقطة ثقة كاملة.
المشكلة أن حماية كمية ضخمة من الذاكرة تحتاج إلى موازنة بين الأداء والأمان. بعض هذه التصاميم توفر السرية والتكامل بدرجات مختلفة، لكنها لا توفر ضمانًا كاملًا يسمى Freshness.
#ما المقصود بـ Freshness؟
يمكن للمعالج أن يعرف أن البيانات التي استعادها مشفرة بالمفتاح الصحيح. لكن بدون آلية Freshness قوية، قد لا يعرف أن هذه البيانات هي أحدث نسخة يفترض أن تكون موجودة في ذلك العنوان.
تخيل ملفًا مشفرًا بشكل صحيح لكنه يعود إلى نسخة أقدم. التشفير نفسه ما زال صحيحًا، لذلك مجرد فك التشفير بنجاح لا يخبرك أن القيمة حديثة.
DDRop يستغل هذه الفجوة مباشرة. بدل أن يحاول سرقة البيانات من ناقل الذاكرة، يمنع عملية كتابة محددة ويترك القيمة القديمة في مكانها.
عندما يعود المعالج لاحقًا للقراءة، يجد Ciphertext صالحًا ويفك تشفيره بصورة طبيعية. لكنه في الحقيقة يتعامل مع بيانات كان يفترض أن تختفي بعد آخر عملية كتابة.
#كيف يُسقط DDRop عملية الكتابة؟
الهجوم يستخدم لوحة من المفاتيح الإلكترونية الموضوعة على ناقل DDR5. اللوحة تعمل بسرعات الذاكرة الأصلية، وهذا فرق مهم عن عدد من الهجمات السابقة التي احتاجت إلى إبطاء الناقل.
عند الرغبة في إسقاط عملية كتابة، يتسبب الـ Interposer بخطأ متعمد على ناقل الأوامر. بعدها يمنع الإشارة التي تستخدمها وحدة الذاكرة للإبلاغ عن هذا الخطأ للمعالج.
وحدة الذاكرة تتخلص من الأمر بسبب الخطأ. المعالج في المقابل لا يتلقى إشعارًا يخبره أن العملية لم تنفذ.
النتيجة بسيطة وخطيرة. النظام يتصرف كأن الكتابة حدثت، بينما القيمة القديمة ما زالت في الذاكرة.
#لماذا DDR5 لم يمنع الهجوم؟
هجمات سابقة على الذاكرة اعتمدت على التلاعب بالعناوين نفسها. لكن DDR5 أعاد تصميم جزء من بروتوكول الأوامر بطريقة تجعل بعض حيل تبديل العناوين القديمة غير عملية.
هذا حد من تقنيات مثل تلك المستخدمة في Battering RAM على DDR4. DDRop تجاوز المشكلة بطريقة مختلفة تمامًا، فهو لا يحتاج إلى تبديل عنوان بآخر.
بدل تغيير وجهة الذاكرة، يقوم ببساطة بإسقاط عملية الكتابة. وهكذا يترك بيانات قديمة داخل المكان الذي كان يفترض أن يستقبل القيمة الجديدة.
الباحثون يصفون DDRop بأنه أول Active Hardware Interposer عملي على خوادم DDR5 الحديثة بهذا الأسلوب. هذه نقطة مختلفة عن هجمات DDR5 السلبية مثل TEE.fail التي تراقب حركة الذاكرة بدل تغيير ما يحدث عليها.
#من إسقاط Write إلى السيطرة على Intel TDX
الجزء الأكثر إثارة في البحث ظهر مع Intel TDX. التقنية تعتمد على جداول صفحات محمية تستخدمها البيئة الموثوقة للتحكم في ترجمة عناوين الذاكرة الخاصة بالآلات الافتراضية السرية.
عندما ينشئ TDX صفحة جديدة لهذه الجداول، تقوم وحدة TDX بكتابة مدخلات فارغة لتهيئتها بشكل آمن. DDRop يستطيع إسقاط عمليات الكتابة هذه.
إذا لم تصل القيم الفارغة، تبقى في الصفحة بيانات قديمة حضرها المهاجم مسبقًا. هذه البيانات يمكن أن تفك إلى مدخلات Page Table يختارها المهاجم.
من هنا تتحول المشكلة من قيمة قديمة في الذاكرة إلى Primitive قوية جدًا. آلة افتراضية يسيطر عليها المهاجم تستطيع إعادة ربط ذاكرتها بعناوين فعلية أخرى داخل RAM.
وهذا يفتح الطريق للقراءة والكتابة في مناطق لم يكن يفترض أن تستطيع تلك الآلة الوصول إليها.
يوضح البحث كيف تتحول عملية إسقاط الكتابة إلى تلاعب بذاكرة محمية داخل Intel TDX.
#قراءة ذاكرة الضحية وتحويلها إلى Debug Mode
في وضع TDX الافتراضي المعروف باسم Logical Integrity، استخدم الباحثون القدرة الجديدة للوصول إلى ذاكرة آلة افتراضية أخرى. وتمكنوا من قراءة بيانات خاصة يفترض أن تبقى محمية من الـ Hypervisor.
كما استهدفوا إعداد Debug داخل بنية TDX. عند تفعيل هذا الوضع يصبح بإمكان الـ Hypervisor استخدام واجهات مخصصة لقراءة ذاكرة الآلة الافتراضية بشكل أوضح.
الباحثون استخدموا DDRop للتأثير في القيمة المسؤولة عن هذا الإعداد. وبعد نجاح العملية تمكنوا من نسخ ذاكرة الضحية بصيغة Plaintext.
ثم أعادوا البيانات الأصلية إلى مكانها. النتيجة أن الآلة المستهدفة تستمر في العمل دون مؤشر واضح داخلها على أن ذاكرتها قُرئت بهذه الطريقة.
هذه النتيجة مرتبطة بوضع Logical Integrity. الباحثون يقولون إن وضع Cryptographic Integrity الأقوى في TDX يمنع جزءًا من هذا التلاعب لأنه يضيف حماية أقوى عند تغيير بيانات تخص نطاق مفتاح مختلف.
#الأخطر، تزوير Remote Attestation
الحوسبة السرية لا تعتمد فقط على تشفير الذاكرة. هناك أيضًا Remote Attestation، وهي الآلية التي تسمح لطرف بعيد بالتأكد أن الآلة الافتراضية بدأت بالحالة والبرمجيات المتوقعة.
Intel TDX يحتفظ بقياس إطلاق يسمى Launch Measurement. هذا القياس يدخل ضمن التقرير الذي يستطيع العميل استخدامه للتحقق من أن الـ VM الموثوق هو فعلًا ما تم تشغيله.
الباحثون استهدفوا قياس آلة افتراضية يسيطر عليها المهاجم نفسه. وباستخدام مدخلات الصفحات المزورة تمكنوا من الكتابة إلى البنية التي تحتوي على القياس.
بعدها استبدلوا القياس بقيمة تخص حملًا موثوقًا. عند طلب تقرير Attestation، أعادت TDX تقريرًا صحيح التوقيع لكنه يحتوي على القياس المزور.
مثال الباحثين على تغيير قيمة MRTD المستخدمة ضمن قياس إطلاق Intel TDX.
هنا تظهر نقطة مهمة. Cryptographic Integrity لا يضيف Freshness، لذلك يرى الباحثون أن تزوير Attestation لآلة المهاجم نفسها قد يبقى ممكنًا حتى مع هذا الوضع الأقوى.
لكن هذه الجزئية لم تُختبر عمليًا على جهاز يدعم Cryptographic Integrity. نظام الاختبار لدى الفريق لم يدعم الوضع، لذلك تبقى النتيجة في هذا الجزء تحليلًا تقنيًا مدعومًا بتصميم النظام وليست تجربة مؤكدة على العتاد نفسه.
#ماذا عن AMD SEV-SNP؟
التأثير على AMD SEV-SNP أضيق من النتيجة التي حققها الفريق على Intel TDX. الباحثون استخدموا إسقاط الكتابة أثناء عملية نقل صفحات الذاكرة ليستنسخوا محتوى صفحة تخص الضحية داخل صفحة أخرى.
هذا لا يساوي السيطرة الكاملة التي عُرضت في سيناريو TDX. كما أن هجمات تفعيل Debug وتزوير Attestation المذكورة في البحث مرتبطة ببنية Intel TDX وليست نتيجة عامة على AMD.
مع ذلك، الجذر واحد. ذاكرة SEV-SNP المشفرة لا تملك Freshness تسمح لها باكتشاف أن عملية كتابة اختفت وأن قيمة قديمة أُعيد استخدامها.
ولهذا يصنف الباحثون AMD SEV-SNP ضمن التقنيات المتأثرة بالمبدأ الأساسي للهجوم.
#وهل Intel Scalable SGX متأثر؟
نعم، Intel Scalable SGX يدخل ضمن الأنظمة التي يذكرها البحث بسبب غياب Freshness في تصميم حماية الذاكرة القابل للتوسع.
لكن يجب التفريق بينه وبين Intel Client SGX الأقدم الموجود في بعض معالجات الأجهزة المكتبية والمحمولة. ذلك التصميم استخدم شجرة تكامل عتادية مع عدادات Freshness تستطيع اكتشاف إعادة استخدام البيانات القديمة.
لذلك Client SGX ليس ضمن الهدف نفسه. Intel أوقفت هذه التقنية على الأجيال الحديثة، بينما تركز DDRop على بنى الخوادم الحالية.
#ماذا عن NVIDIA وArm؟
وحدات NVIDIA المستخدمة في Confidential Computing ليست هدفًا مباشرًا لهذا النوع من الـ Interposer بحسب الباحثين. السبب أن الذاكرة المستهدفة توجد داخل حزمة العتاد بطريقة تمنع تركيب اللوحة نفسها على ناقل DDR5 بين المعالج ووحدة الذاكرة.
أما Arm CCA فلم يختبره الفريق. الباحثون يرون أنه قد يكون معرضًا للمبدأ نفسه، لكن لا توجد نتيجة تجريبية في البحث تثبت ذلك.
وهذه نقطة يجب عدم تجاوزها عند الحديث عن الهجوم. عدم الاختبار لا يعني إثبات الإصابة.
#هل يعني DDRop أن AWS أو Azure أو Google Cloud تم اختراقها؟
لا. البحث لا يقدم دليلًا على اختراق AWS أو Microsoft Azure أو Google Cloud باستخدام DDRop.
هذه المنصات توفر تقنيات Confidential Computing تعتمد على عتاد من Intel وAMD. لكن إثبات ضعف في طبقة عتادية تستخدمها خدمات سحابية لا يساوي إثبات استغلال الخدمة نفسها.
الهجوم يحتاج إلى وصول مادي للخادم، إضافة إلى تحكم برمجي مميز في النظام. الباحثون ذكروا سيناريوهات مثل موظف مركز بيانات خبيث، تلاعب في سلسلة التوريد، أو وصول قسري إلى العتاد.
حتى وقت الإفصاح، لم يقدم الفريق دليلًا على استخدام DDRop أو Interposer نشط مماثل خارج المختبر.
#لماذا لا يوجد Patch بسيط؟
المشكلة ليست Bug صغيرًا في Driver يمكن إصلاحه بتحديث سريع. أصل المشكلة موجود في نموذج حماية الذاكرة نفسه.
التشفير الحالي يستطيع حماية السرية بكفاءة على مساحات ذاكرة ضخمة. لكن إضافة Integrity وFreshness كاملتين لكل البيانات تحتاج إلى تصميم عتادي أكثر تعقيدًا وكلفة.
يمكن للبرمجيات والـ Firmware رفع صعوبة الاستغلال. من الخيارات التي يناقشها الباحثون تقييد بعض واجهات إدارة الذاكرة، والتحقق من وصول عمليات الكتابة الحساسة، ومحاولة اكتشاف وجود Interposer أثناء الإقلاع.
لكن هذه الإجراءات لا تضيف Freshness إلى محرك تشفير الذاكرة نفسه. لذلك هي دفاعات تقلل مساحة الهجوم ولا تعالج الجذر بالكامل.
#موقف AMD وIntel
بعد الإفصاح المنسق في 14 سبتمبر 2026 نشرت AMD نشرتها الأمنية AMD-SB-3048. الشركة أقرت بالتقنية، لكنها اعتبرتها هجومًا ماديًا على ناقل الذاكرة يقع خارج Threat Model المنشور لـ SEV-SNP.
AMD قالت إنها لا تخطط لإصدار CVE أو Mitigation استجابة لهذا البحث. كما نشرت قائمة بمعالجات EPYC وInstinct التي تدخل ضمن المنتجات المتأثرة في نشرتها.
Intel تتخذ موقفًا مشابهًا تجاه هجمات الـ Physical Interposer على ذاكرة الخادم. الشركة تعتبر هذا النوع خارج حدود الحماية التي تعد بها تقنيات تشفير الذاكرة الحالية، ولا تتعامل معه كثغرة تقليدية تستوجب CVE بالضرورة.
في الوقت نفسه، تصف Intel هذا المجال بأنه خارج نطاق النموذج الحالي لكنه ليس خارج الاهتمام. وبعض معالجات Xeon توفر أصلًا وضع Cryptographic Integrity الذي يمنع جزءًا من نتائج DDRop، لكنه لا يحل مشكلة Freshness.
#ما الذي قد يحل المشكلة فعليًا؟
الحل الدائم يحتاج إلى ذاكرة لا تتحقق فقط من أن البيانات صحيحة ومشفرة. يجب أن تعرف أيضًا أن القيمة هي النسخة الحالية وليست Ciphertext قديمًا أعيد استخدامه.
أحد الاتجاهات التي طرحتها Intel هو Cache-Line Versioning. الفكرة تضيف مفهوم إصدار لكل جزء صغير من الذاكرة حتى يصبح من الممكن تمييز القيمة الحالية من القديمة.
لكن الباحثين يقولون إن من غير الواضح بعد ما إذا كان هذا التصميم سيمنع DDRop بالشكل المطلوب. ولا توجد في الإفصاح الحالي إجابة نهائية من Intel حول ذلك.
#من TEE.fail إلى Battering RAM ثم DDRop
قيمة DDRop تظهر أكثر عند وضعه بجانب الأبحاث السابقة. TEE.fail أثبت أن مراقبة DDR5 يمكن أن تكشف معلومات عبر Side Channels، لكنه هجوم سلبي ويراقب الناقل بدل التلاعب به.
Battering RAM انتقل إلى الهجوم النشط وغيّر ما تراه الذاكرة، لكنه اعتمد على تبديل العناوين وكان عمليًا على DDR4. تصميم DDR5 الجديد جعل تلك الحيلة أصعب.
DDRop اختار مسارًا ثالثًا. لا يقرأ البيانات من الناقل ولا يبدل العنوان، بل يجعل بعض الكتابات تختفي.
وهنا يتضح سبب أهمية البحث. التشفير لم يُكسر رياضيًا، لكن الافتراض المحيط به هو الذي انكسر.
#الخلاصة
DDRop يوضح أن حماية الذاكرة لا تتوقف عند سؤال واحد وهو هل البيانات مشفرة أم لا. يمكن للبيانات أن تكون مشفرة بشكل صحيح ومع ذلك تكون قديمة، وهذه الفجوة وحدها تكفي أحيانًا لقلب نموذج الحماية بالكامل.
على Intel TDX وصل الباحثون من إسقاط Write واحد إلى التحكم في Secure Page Tables، ثم قراءة ذاكرة محمية وتفعيل Debug وتغيير قياس Attestation. وعلى AMD SEV-SNP أثبتوا قدرة أضيق تسمح بنقل محتوى صفحات الضحية بطريقة لا يفترض أن تكون ممكنة.
الهجوم ليس سهلًا من ناحية المتطلبات، فهو يحتاج تحكمًا برمجيًا قويًا ووصولًا ماديًا للخادم. لكنه في المقابل يستخدم عتادًا تكلفته أقل من 200 دولار ويمكن تركيبه خلال وقت قصير.
وهذه هي الرسالة الأهم. عندما يكون Threat Model مبنيًا على أن المهاجم قد يملك الـ Hypervisor لكن لا يستطيع العبث بذاكرة الخادم فعليًا، فإن قطعة صغيرة على ناقل DDR5 تستطيع تحويل ذلك الافتراض إلى نقطة ضعف.
التشفير يحمي محتوى البيانات. أما Freshness فهي التي تخبر النظام أن ما يقرأه هو فعلًا آخر شيء كتبه.
