شركة AMD تثير الجدل برفض مكافأة مالية لباحث أمني بعد تأخير طويل في معالجة ثغرة حساسة

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

الباحث الأمني المعروف باسم MrBruh اكتشف أن برنامج التحديث لدى AMD كان يجلب قائمة التحديثات عبر HTTPS، لكنه ينزّل الملفات التنفيذية نفسها عبر HTTP غير المشفر. الأخطر من ذلك أن الأداة، وفق تحليله، لم تكن تُجري تحققاً حقيقياً من الشهادات الرقمية أو توقيعاً رقمياً مشفراً قبل تشغيل الملف المُحمّل، مكتفية بفحص CRC32، وهو فحص سلامة لا يرقى إلى مستوى التحقق الأمني المشفر.

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

بعد اكتشاف الثغرة في يناير، أبلغ الباحث شركة AMD عبر برنامج مكافآت الثغرات في فبراير. الرد الأول كان إغلاق البلاغ باعتباره “خارج النطاق” لأنه يعتمد على هجوم من نوع رجل في الوسط ويؤثر على أدوات اختيارية. هذا التصنيف يعني ببساطة: لا مكافأة.

لاحقاً، وبعد انتشار القصة، عاد فريق الاستجابة للحوادث الأمنية داخل الشركة لمراجعة المسألة، وتم تخصيص رقم CVE-2026-40677 للثغرة مع درجة خطورة 7.7 وفق معيار CVSS 4.0. استغرق المسار الكامل 124 يوماً حتى انتهاء الحظر ونشر التفاصيل. وخلال ذلك، طلبت AMD من الباحث حذف منشوره بدعوى عدم التزامه بشروط البرنامج.

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

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

في نشرتها الرسمية، أكدت AMD أن أدوات مثل Ryzen Master وµProf وManagement Console تم تحديثها، وأن جميع اتصالات التحديث أصبحت عبر HTTPS مع تطبيق تحقق من التوقيع. لكن الباحث أشار إلى أنه تحقق من استخدام HTTPS، دون أن يجد آلية توقيع رقمية مشفرة حقيقية، بل مجرد فحص CRC32.

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

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

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

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