if-forget/cve-2026-52134-libiec61850إشعار فني عام وأدلة إعادة إنتاج لثغرة CVE-2026-52134 التي تؤثر على معالجة إعادة إرسال GOOSE في libiec61850 الإصدار v1.6.
تم تعيين CVE-2026-52134. نشر سجل CVE المقابل قيد الانتظار.
src/goose/goose_receiver.cparseGoosePayload()لا يرفض مسار استقبال مشترك GOOSE في libiec61850 الإصدار 1.6 بشكل كافٍ بعض رسائل GOOSE المعاد تشغيلها أو القديمة قبل تحديث الحالة المرئية للمشترك واستدعاء دالة الاستدعاء المسجلة.
أظهرت تجربتان مضبوطتان سلوكًا مترابطًا في نفس مسار الاستقبال:
stNum أقل: بعد أن عالج المشترك stNum=2، تسببت إعادة تشغيل إطار الملتقط سابقًا في قيام دالة الاستدعاء بالإبلاغ عن الحالة والبيانات الأقدم مرة أخرى.stNum=1sqNum غير متزايد: عند إعادة تشغيل إطار ملتقط سابقًا بنفس stNum ولكن sqNum أقدم، تم تمييز الإطار على أنه غير صالح، لكن استدعاءات دالة الاستدعاء ما زالت تحدث وبقيت البيانات المعاد تشغيلها مرئية.تُعرض هذه كملاحظتين مترابطتين لمشكلة واحدة في معالجة إعادة التشغيل/حداثة الرسائل، وليس كـ CVE منفصلين.
يجب أن يكون المهاجم قادرًا على:
0x88B8هذا ليس هجومًا عن بُعد عشوائيًا عبر الإنترنت.
يتحقق منطق الاستقبال ذو الصلة من sqNum عندما يتساوى stNum المستلم مع stNum المخزن. مسار الكود المختبر لا يرفض stNum أقل قبل تحديث حالة المشترك واستدعاء دالة الاستدعاء.
لم يتم تعديل ملف المكتبة المختبر. كانت النسخة الأصلية ونسخة العمل من src/goose/goose_receiver.c بنفس قيمة SHA-256:
c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b
veth0 / veth1 في Linuxtcpdumpأنتجت أداة الاختبار انتقالات حالة مضبوطة وطبعت قيم stNum و sqNum والصحة والبيانات المرئية لدالة الاستدعاء. لم يتم تعديل ملف المكتبة القابل للاستغلال نفسه.
أرسل الناشر المتحكم فيه حالتين:
State A: stNum=1, sqNum=0, data=1111
State B: stNum=2, sqNum=0, data=2222
احتوى التقاط الحزمة الأساسي على إطارَي GOOSE بهذا الترتيب:
Frame 1: stNum=1, sqNum=0
Frame 2: stNum=2, sqNum=0
احتوى إخراج المشترك أيضًا على استدعاء مساعد لـ stNum=1, sqNum=0 مُعلّم بأنه valid=false قبل الحالة B. يُحتفظ بهذا الاستدعاء المساعد في الأدلة ولكن لا يُستخدم كأساس لاستنتاج التراجع. الحالة الحاسمة قبل إعادة التشغيل كانت الاستدعاء اللاحق الذي يحتوي على stNum=2 وقيمة البيانات 2222.
حمّل سكربت إعادة التشغيل التقاط الأساس ذا الإطارين، وحدد الإطار 1، وأرسله مرة واحدة عبر veth0.
مباشرة قبل إعادة التشغيل، أبلغت دالة الاستدعاء:
stNum=2, sqNum=0, valid=true, allData={2222}
بعد إعادة تشغيل الإطار القديم مرة واحدة، أبلغت دالة الاستدعاء:
stNum=1, sqNum=0, valid=true, allData={1111}
يوضح هذا تراجعًا مرصودًا في حالة المشترك من stNum=2 إلى stNum=1 بعد إعادة تشغيل إطار ملتقط سابقًا بقيمة stNum أقل.
تم إرسال أربع نسخ إضافية من نفس الإطار القديم. احتوت جميعها على stNum=1, sqNum=0.
تم الإبلاغ عن النسخ اللاحقة على أنها valid=false، لكن أرقام الاستدعاءات استمرت في الزيادة وبقيت البيانات المعاد تشغيلها مرئية:
تُظهر هذه الملاحظة الثانوية أن تمييز إطار مكرر على أنه غير صالح لم يمنع تسليمه إلى دالة الاستدعاء في مسار الاستقبال المختبر.
استخدم إعادة إنتاج سابقة الناشر والمشترك المثالين الرسميين. أنتج الناشر تسلسلًا طبيعيًا باستخدام:
stNum=1
sqNum=0, 1, 2, 3
تمت إعادة تشغيل أول إطار ملتقط (stNum=1, sqNum=0) بعد أن كان المشترك قد عالج بالفعل القيمة اللاحقة للتسلسل.
تم الإبلاغ عن النسخ المعاد تشغيلها على أنها غير صالحة لأن sqNum=0 المستلم لم يكن أحدث من قيمة التسلسل المخزنة. ومع ذلك، استمر المشترك في طباعة أحداث دالة الاستدعاء التي تحتوي على البيانات المعاد تشغيلها:
تدعم هذه التجربة ملاحظة أضيق ولكنها مرتبطة:
لقطات الشاشة الأولية الخام لإعادة التشغيل محفوظة كمواد داعمة:
تحتوي تلك الصور الخام على تحذيرات استيراد وحدات اختيارية غير ذات صلة من Scapy. لم تمنع التحذيرات السكربت من الإبلاغ عن إطارات GOOSE الملتقطة وإكمال الإرسال، لكن لقطات الشاشة الأنظف أعلاه مفضلة لمراجعة النتيجة التقنية.
توضح التجربتان فرعين مختلفين لنفس مشكلة إعادة تشغيل/حداثة رسائل GOOSE:
| الملاحظة | الرسالة المستلمة | النتيجة المرصودة |
|---|---|---|
إعادة تشغيل stNum أقل | مخزّن stNum=2؛ استُلم stNum=1 قديم | تم تسليم الحالة والبيانات القديمة إلى دالة الاستدعاء والإبلاغ عنها على أنها صالحة في التشغيل المختبر |
إعادة تشغيل sqNum غير متزايد | نفس stNum؛ استُلم sqNum أقدم أو مكرر | تم الإبلاغ عن الرسالة على أنها غير صالحة، لكن استدعاءات دالة الاستدعاء وتسليم البيانات المعاد تشغيلها استمرت |
الملاحظة الأولى هي النتيجة الأساسية لـ CVE لأنها توضح تراجعًا من حالة أحدث إلى حالة أقدم. الملاحظة الثانية هي دليل داعم حول كيفية استمرار عمليات إعادة التشغيل غير الصالحة لنفس الحالة عبر مسار دالة الاستدعاء.
التأثير المرصود على مستوى البرمجيات هو:
stNum أحدث إلى stNum أقدم.قد تعالج التطبيقات التي تستهلك بيانات دالة الاستدعاء دون فرض حداثة مستقل قيمًا قديمة أو معاد تشغيلها.
يعتمد التأثير النهائي على تطبيق المشترك والتكوين ومنطق التعشيق ومنطق الحماية.
لم يتم اختبار أو تشغيل أي مرحل حماية فيزيائي أو دائرة فصل أو قاطع دائرة أو شبكة محطة فرعية إنتاجية في هذه التجارب.
قبل تحديث حالة المشترك أو استدعاء دالة الاستدعاء:
stNum مستلمًا أقدم من آخر stNum مقبول.stNum دون تغيير، ارفض sqNum غير متزايد.stNum غير المتوقع وقيم sqNum المتكررة.توفر الصور التالية معلومات حول مصدر الأدلة والبيئة. تدعم إعادة الإنتاج ولكنها ليست مطلوبة بشكل فردي لفهم النتيجة الرئيسية.
النتيجة الموضحة هي قبول إعادة التشغيل وتسليم حالة قديمة. لا تعتمد على إثبات تمكين المصادقة التشفيرية في النشر المختبر.
أبلغ عن: