كيف يفتح خطأ من 504 بايت باب السيطرة على UEFI؟

29 أكتوبر 2026 | تحليل تقني للثغرة CVE-2026-97631

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

هذا بالضبط ما يجعل الثغرة CVE-2026-97631 لافتة. فالخلل ليس في Linux أو Windows، ولا في تطبيق ويب أو خدمة تقليدية؛ بل في جزء من الشيفرة المستخدمة لبناء برنامج الإقلاع الثابت UEFI Firmware. أثناء محاولة الجهاز الإقلاع عبر الشبكة، تستطيع رسالة خطأ من بروتوكول ICMP، في ظروف محددة، الكتابة خارج مساحة ذاكرة مخصصة لها. النتيجة قد تكون توقف الإقلاع، أو تنفيذ شيفرة داخل بيئة تسبق نظام التشغيل.

حصلت الثغرة على تقييم 9.5 من 10 وفق CVSS v4.0. لكن الرقم وحده لا يشرح طبيعة الخطر: فهم الثغرة يتطلب معرفة أين تقع في تسلسل الإقلاع، ولماذا تُعالج رسائل الشبكة في هذه المرحلة، وكيف يمكن لخطأ حسابي في مؤشر ذاكرة أن يغير مسار التنفيذ.

#من زر التشغيل إلى نظام التشغيل: أين توجد نقطة الضعف؟

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

أحد أشهر المشاريع المفتوحة المستخدمة لبناء هذه الشيفرة هو TianoCore EDK II، أو اختصارًا EDK2. تستخدم شركات تصنيع العتاد والبرمجيات الثابتة أجزاء من هذا المشروع وتخصصها لمنصاتها، لذلك قد ينتقل خطأ في مكوّن مشترك إلى منتجات مختلفة. ومع ذلك، استخدام EDK2 لا يعني تلقائيًا أن كل جهاز مبني عليه قابل للاستغلال؛ فذلك يتوقف على المكوّنات التي أُدرجت في بناء الـFirmware وطريقة تهيئتها وتشغيلها.

يمر الإقلاع عادة بمراحل تشمل SEC وPEI وDXE، ثم اختيار مسار الإقلاع عبر BDS. وخلال تجهيز الإقلاع الشبكي، يُستخدم برنامج تشغيل اسمه:

NetworkPkg/UefiPxeBcDxe

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

الصورة المبسطة لمسار الخطر تبدو هكذا:

Power on
   |
   v
UEFI Firmware: SEC -> PEI -> DXE
                          |
                          v
                 UefiPxeBcDxe
                 (PXE network boot)
                          |
                          v
                ICMP error received
                          |
                          v
                 Mode.IcmpError
                  [504 bytes]
                          |
                          v
                 Out-of-bounds write
                          |
                  +-------+-------+
                  |               |
                  v               v
             Boot failure    Possible code
             / DXE crash     execution in DXE

هذه ليست ثغرة في نظام يعمل منذ ساعات؛ إنها ثغرة في أحد المكونات المسؤولة عن إحضار النظام إلى الذاكرة.

#ماذا نعرف عن CVE-2026-97631؟

كشف الباحثان Alex Matrosov من Anthropic وDan Holmes-Mitra من Google الخلل، ثم نشر مشروع TianoCore تنبيهًا أمنيًا في 22 أكتوبر 2026. يشمل الخلل معالجات رسائل الأخطاء الخاصة بـIPv4 وIPv6 في مكوّن الإقلاع الشبكي.

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

#أصل المشكلة: كيف يتجاوز خطأ نسخ 504 بايت حدود الذاكرة؟

التفاصيل الأكثر حساسية تقنيًا تبدأ من حقل داخل بنية بيانات خاصة ببرنامج تشغيل PXE:

Mode.IcmpError

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

حدد التنبيه الأمني دالتين مرتبطتين بالخلل:

PxeBcIcmpErrorDpcHandle
PxeBcIcmp6ErrorDpcHandle

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

للتوضيح، هذا نموذج منطقي مبسّط لفكرة النسخ الآمن، وليس اقتباسًا من شيفرة EDK2 الأصلية:

#define ICMP_ERROR_CAPACITY 504

size_t offset = 0;

for (each_received_fragment) {
    size_t remaining = ICMP_ERROR_CAPACITY - offset;
    size_t copy_len = min(fragment_len, remaining);

    copy(destination + offset, fragment, copy_len);
    offset += copy_len;

    if (offset == ICMP_ERROR_CAPACITY) {
        break;
    }
}

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

في مصطلحات استغلال الذاكرة، يسمى ذلك:

Out-of-bounds Write
Buffer Overflow
Memory Corruption

وهذه النقطة هي جوهر الثغرة: المهاجم لا يحتاج إلى إقناع نظام التشغيل بتشغيل ملف خبيث؛ بل يحاول التأثير في شيفرة منخفضة المستوى تتعامل مع بيانات شبكة غير موثوقة أثناء الإقلاع.

#من رسالة شبكة إلى تعطيل الإقلاع أو تغيير تدفق التنفيذ

وفق التنبيه الرسمي، يمكن إيصال رسالة خطأ ICMP أحادية الوجهة (Unicast) إلى عنوان الجهاز أثناء الإقلاع عبر PXE، سواء باستخدام IPv4 أو IPv6. ليس من الضروري أن يكون المُرسل على نفس الشبكة المحلية حرفيًا، لكن يجب وجود مسار شبكي يسمح بوصول الرسالة إلى الجهاز في تلك اللحظة؛ وهو شرط قد تحدّه إعدادات العزل والتوجيه والجدران النارية.

بعد وصول الرسالة المتجاوزة للحجم، يوجد مساران مختلفان للأثر:

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

الثاني: تنفيذ شيفرة داخل بيئة DXE. يشير التنبيه إلى أن المهاجم الذي يعرف بناء الـFirmware المستهدف يستطيع، في ظروف مناسبة، تشكيل حدث مزيف داخل البيانات الفاسدة. وعند استدعاء:

CoreSignalEvent()

قد يُحوَّل مسار التنفيذ إلى بايتات يتحكم بها المهاجم. يصف التنبيه هذا السيناريو بأنه تنفيذ خلال مرحلة DXE وعلى مستوى امتياز Ring 0.

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

#لماذا يمثل التنفيذ قبل نظام التشغيل خطرًا مختلفًا؟

في الهجمات التقليدية، يعمل المهاجم داخل بيئة تحتوي غالبًا على سجلات للنظام، وبرامج حماية، وآليات مراقبة وسياقات صلاحيات واضحة. أما هنا، فالشيفرة الخبيثة المحتملة تُنفَّذ قبل تحميل نظام التشغيل وقبل بدء دفاعاته المعتادة.

توجد هنا ثلاثة مستويات يجب الفصل بينها:

أولًا، Secure Boot: يتحقق من موثوقية مكونات ضمن سلسلة الإقلاع، لكنه ليس آلية عامة لفحص سلامة كل رسالة شبكة تتلقاها شيفرة الـFirmware. لذلك لا يُعد تفعيله وحده علاجًا لخطأ فساد الذاكرة داخل برنامج تشغيل PXE.

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

ثالثًا، الاستمرارية (Persistence): لا يمنح فساد الذاكرة الناتج من الرسالة، بمفرده، موطئ قدم دائمًا بعد إعادة التشغيل. إلا أن تنفيذ شيفرة مبكرًا قد يُستخدم نقطة انطلاق لمحاولة تثبيت مكوّن آخر قادر على الاستمرار، إذا سمحت الظروف بذلك.

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

#هل كل الخوادم عرضة للخطر؟

انتشار شيفرة EDK2 في منظومة تصنيع البرمجيات الثابتة واسع، ولذلك قد يمتد أثر الخلل إلى منتجات ومورّدين متعددين. لكن العنوان القائل إن «كل الخوادم تقريبًا قابلة للاختراق» يتجاوز ما يمكن إثباته من الإفصاح المتاح؛ إذ لا توجد قائمة مكتملة بالنماذج والإصدارات المتأثرة لدى جميع الشركات.

لإثبات قابلية جهاز معين للتأثر، يلزم التمييز بين أربع حقائق منفصلة:

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

#إفصاح مبكر وإصلاح في المستودع: لماذا لم تنته المشكلة؟

تكشف السجلات العامة للمشروع تسلسلًا يستحق الانتباه:

المفارقة أن الصفحة الأمنية ظلت تعرض وصفًا يفيد بعدم توفر إصدار مرقّع، رغم دمج التغيير في الشيفرة المصدرية. لا يوجد تناقض تقني بالضرورة: دمج إصلاح في الفرع الرئيسي لا يساوي إصدار حزمة مستقرة جديدة، ولا يساوي بناء وتوقيع وتوزيع تحديث BIOS/UEFI لكل طراز من الخوادم.

يتطلب الانتقال من إصلاح مشروع مفتوح إلى حماية جهاز إنتاجي سلسلة أطول: تبنّي المورد للإصلاح، ودمجه مع تخصيصاته، واختبار صورة الـFirmware، ثم طرح التحديث المناسب للجهاز. وقد يطول هذا المسار خصوصًا في الأجهزة القديمة أو التي انتهى دعمها.

#كيف تُقيَّم الأنظمة عمليًا؟

يبدأ التقييم بجرد الشركة المصنعة للـFirmware وإصداره وطراز المنصة، ثم ربطها بإشعارات المورد الرسمية. في أنظمة Linux يمكن جمع بعض معلومات التعريف بالأوامر التالية:

sudo dmidecode -s bios-vendor
sudo dmidecode -s bios-version
sudo dmidecode -s system-product-name
sudo efibootmgr -v

أما في Windows فيمكن قراءة معلومات الـFirmware باستخدام PowerShell:

Get-CimInstance -ClassName Win32_BIOS |
    Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

هذه أوامر جرد وليست اختبار استغلال أو إثباتًا لوجود الثغرة. كذلك لا تكفي قائمة الإقلاع الظاهرة في النظام لتأكيد أن مسار PXE معطّل بالكامل؛ وقد تتطلب الحقيقة النهائية فحص إعدادات UEFI الفعلية أو واجهة إدارة الخادم والرجوع إلى نشرة الشركة المصنعة.

عندما لا يكون الإقلاع الشبكي مطلوبًا، يؤدي تعطيله إلى إزالة مسار التعرض الذي يصفه التنبيه. وعندما يكون ضروريًا، يصبح تقييد حركة الشبكة المسموح بوصولها إلى بيئة التزويد، وتقليل الشبكات القادرة على مخاطبة الأجهزة خلال الإقلاع، ومتابعة تحديثات الـFirmware من الشركة المصنعة إجراءات مرتبطة مباشرة بالخطر. يظل Secure Boot وTPM مهمين كجزء من دفاعات المنصة، لكنهما لا يصلحان خطأ النسخ في مكوّن PXE.

#ثغرة واحدة تكشف مشكلة أوسع

ليست CVE-2026-97631 أول تذكرة بأن مساحة الهجوم تبدأ قبل نظام التشغيل. فقد أظهرت أبحاث PixieFail خطورة أخطاء مكدس الشبكات المستخدم في الإقلاع، بينما كشفت LogoFail كيف يمكن لمعالجة بيانات تبدو غير تنفيذية، مثل الصور المعروضة عند بدء التشغيل، أن تفتح مسارًا للسيطرة على مكونات مبكرة. تختلف العلل وآليات الاستغلال، لكن القاسم المشترك هو انتقال بيانات غير موثوقة إلى بيئة عالية الامتياز لا تُراقب بالطريقة نفسها التي تُراقب بها أنظمة التشغيل.

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

ولهذا لا تكفي قراءة «9.5» أو «تنفيذ شيفرة عن بُعد» لفهم الخطر. السؤال الحقيقي هو: أي شيفرة تعمل قبل أن يبدأ النظام بفرض حدوده الأمنية، وما مقدار الثقة الذي تمنحه للبيانات التي تستقبلها؟

في هذه الثغرة، كانت الإجابة المختبئة داخل معالج بسيط لأخطاء ICMP.

#المصادر والمراجع التقنية

1. TianoCore — التنبيه الأمني الرسمي GHSA-99cj-7hg9-mp4m
2. TianoCore — إصلاح الخلل واختباراته، PR #13302
3. TianoCore — طلب الإصلاح الأصلي، PR #13200
4. سجل الثغرة CVE-2026-97631
5. Red Hat — معلومات الثغرة وتقييمها
6. Ars Technica — التقرير الأصلي المنشور في 27 أكتوبر 2026