تم تحديث صور Docker الخاصة بـ Teku و Besu بعد حادثة eMudhra، حيث إن مفتاح الشهادة الضعيف يشكل خطرًا على البرامج المتصلة بالخدمات الخارجية، بما في ذلك بعض نشرات مدققي إيثريوم.
- تم إزالة الثقة في الشهادات المتأثرة من صور Docker الخاصة بـ Teku 26.10.3 و Besu 26.10.2 بسبب حادثة eMudhra.
- أكد Teku أن العقد الرئيسية الافتراضية غير متأثرة، ويعتمد مستوى التعرض الفعلي على اتصالات HTTPS ووقت تشغيل Java المستخدم من قبل المشغل.
- المخاطر المعلنة تتعلق بالخدمات المُزَوَّرة وعمليات المُوثِّقين، ولم يتم الإبلاغ عن أي استغلال في إشعار Teku.
بالنسبة للمشغلين، فإن السؤال الأكثر إلحاحًا حاليًا هو: هل سيقبل برنامجهم شهادات مزيفة عند الاتصال بخدمات أخرى؟ يعتمد الجواب على نوع الاتصال وتثبيت Java، لذا فإن تحديث العميل لا يعني أن كل مُحقق يواجه نفس الخطر.
تحديث صور Docker لـ Teku و Besu
لقد أصدر فريق عميل إيثريوم تحديثًا لإصلاح مشكلة شهادة نشأت خارج السلسلة. تشمل التغييرات ذات الصلة كيفية قيام البرنامج بتحديد ما إذا كانت الخدمة البعيدة حقيقية أم لا.
تم إزالة الثقة في جذور الشهادات المؤثرة من صور Docker الخاصة بـ Teku 26.10.3 و Besu 26.10.2. جاء هذا الإصدار نتيجة اكتشاف مفاتيح ضعيفة مرتبطة بمؤسسة إصدار الشهادات eMudhra.
بالنسبة لمشغلي المُصادقين، تكمن المشكلة في أن المهاجمين يزيفون الخدمة التي يتصل بها البرنامج. حسب دور هذه الخدمة، قد تؤدي الاستجابات المزيفة إلى إرباك المهام أو التأثير على وجهة دفع رسوم الكتل.
لكن هذا لا يعني أن كل مُحقق إيثريوم معرض للخطر. وفقًا لإشعار الأمان الخاص بـ Teku، فإن العقدة الافتراضية للشبكة الرئيسية غير متأثرة، ولا توجد حالات تم الإبلاغ عنها حتى الآن تم استغلالها.
الفرق يكمن في طريقة التثبيت. يجب على مشغلي خدمة HTTPS الخارجية التحقق من الاتصالات التي قد لا تكون موجودة في نشر المكونات الكاملة محليًا.
هذه التحديثات تنطبق على بيئة تثبيت محددة. تحتوي صورة Docker بعد التصحيح على تعديلات التشغيل المضمنة داخل الحاوية، بينما قد يستخدم البرنامج المثبت من ملف الأرشيف Java المقدم من قبل المشغل.
أثرت هذه الحادثة على البنية التحتية المحيطة بالموثوقين، ولم تتغير قواعد التوافق الخاصة بالإيثريوم.
Why do certificate issues become security risks?
تساعد الشهادات البرنامج على تحديد ما إذا كان متصلًا بالخدمة المتوقعة. توفر جهات إصدار الشهادات الموثوقة تأييدًا لهوية شهادة الخادم.
هذه الآلية شائعة في المواقع التي تستخدم بروتوكول HTTPS، ولكنها تنطبق أيضًا على التطبيقات التي لا تستخدم المتصفح للاتصال. قد تعتمد خدمات الخلفية أيضًا على هذه المصادقات.
قد تستخدم هيئة إصدار الشهادات شهادات وسيطة تحت شهادات الجذر الموثوقة. يجب الحفاظ على أمان المفاتيح الخاصة المرتبطة بهذه الشهادات الوسيطة، لأنها يمكن أن تُستخدم لإصدار شهادات إضافية.
في هذه الحادثة، لم تكن المشكلة فقط أن شخصًا ما حصل على معلومات تسجيل الدخول العادية للخادم. يمكن استعادة المفاتيح الوسيطة المتأثرة من المعلومات التي تم نشرها مسبقًا.
أشار فريق أمان Go إلى أن هذه الثغرة تسمح باستعادة المفتاح الخاص على مستوى الميكروثانية. كما أشار وصفها إلى أن المهاجمين يمكنهم بعد ذلك إنشاء شهادات ل домينات لا يسيطرون عليها.
قد تقبل التطبيق المعرض للهجوم إذا اعتبر أن الشهادة لا تزال قابلة للتتبع إلى الجهة التي يثق بها. وهكذا، يمكن أن يتجاوز التزوير الهوية الفحوصات المصممة أصلاً لرفض المحتالين.
ومع ذلك، لا يزال المهاجمون بحاجة إلى طريقة ما لاعتراض أو إعادة توجيه اتصالات الضحايا. فالمفاتيح الضعيفة لا تجعلهم يظهرون تلقائيًا بين كل مستخدم وكل خادم.
هذا الشرط يقلل من طرق حدوث الهجوم، لكنه لا يجعل إبطال الشهادة غير ضارة. طالما أن البرنامج يعامل المتنكر كنقطة نهاية حقيقية، فإن اعتراض الشبكة يصبح أكثر خطورة.
بحث Kudelski Security تحقق من طبقات الشهادات المتأثرة. المشكلة تكمن في أن البرنامج قد يقبل الشهادات الصادرة بمفاتيح يمكن للمهاجم إعادة إنشائها.
attributed weak keys to processing errors
أفاد إعلان الحدث الخاص بـ eMudhra أن باحثًا أبلغ عن 8 مفاتيح وسطية ضعيفة في 17 أكتوبر، وسحبت الشركة هذه المفاتيح الثمانية في اليوم التالي.
أفادت الشركة أن هذه الشهادات الوسيطة تم إنشاؤها خلال طقس مفتاح في 30 أبريل 2025. وفقًا للشركة، فإن خطوات التغليف والفك التغليف المعيبة أنتجت نسخًا ضعيفة إضافية بجانب المفاتيح القوية الأصلية.
أشارت الشركة إلى استخدام وحدات أمان مادية معتمدة. وفسرت العطل على أنه ناتج عن خطوة واحدة في العمليات المحيطة، وليس بسبب نقص مثل هذه الأجهزة.
كما أفادت الشركة أن 7 شهادات وسطية لم تُستخدم قط في بيئة الإنتاج، كما أن الشهادة الوسطية المتبقية لم تُصدر أي شهادات بعد. وأوضحت الشركة أن الحادث لم يؤدي إلى اختراق البنية التحتية أو تسريب بيانات.
These statements explain eMudhra's description of its internal operations. However, software vendors must still address another possibility: other parties may exploit recoverable keys.
لا يمكن لمنظومة الشهادات الاعتماد فقط على وعود الجهة التشغيلية الأصلية بعدم إصدار أي محتوى آخر. بمجرد أن يتمكن آخرون من إعادة إنشاء مفتاح التوقيع نفسه، فإن هذا الضمان لم يعد قادرًا على التحكم في جميع الشهادات الممكن إنشاؤها.
لذلك، تجاوزت التدابير الاستجابة الشركة التي أنشأت المفتاح. يجب على مصنعي المتصفحات وموردي أنظمة التشغيل وفرق لغات البرمجة أن تأخذ في الاعتبار ما ستقبله برامج مستخدميها.
سيتم تمرير هذه الإصلاحات إلى المستخدمين عبر تحديثات مختلفة. قد يتلقى المتصفح قائمة حظر، بينما قد يستمر تطبيق Java مستقل آخر في استخدام مجموعة شهادات موثوقة قديمة.
المفاتيح الضعيفة والتطبيقات التي تقبل هذه المفاتيح هي جزآن مختلفان من نفس المشكلة. إلغاء الشهادة يحل المشكلة على مستوى سجلات المؤسسة، بينما يحتاج العميل إلى طريقة موثوقة لتحديد مسارات الثقة التي يجب رفضها.
الخدمات الخارجية تُحدث مخاطر مختلفة للمُحققين
تتكون عقدة إيثريوم من برامج تؤدي مهام مختلفة. تُميّز وثائق عميل إيثريوم بين عميل التنفيذ وعميل التوافق: الأول يعالج تنفيذ المعاملات والحالة، بينما الثاني يتبع توافق إثبات الحصة.
يُضيف برنامج المُحقق مسؤوليات اقتراح الكتل وإثبات السلسلة. يمكن للمشغلين تشغيل هذه المكونات محليًا أو الاتصال بجزء منها عبر خدمات خارجية.
Teku هو عميل توافق، وBesu هو عميل تنفيذ. كلاهما يستخدمان Java، وهو السبب في أن ثقة الشهادات أثناء التشغيل مرتبطة بإصداراتهما.
الخدمات خارج الجهاز المحلي ستضيف طبقة إضافية من التحقق من الهوية لهذا الترتيب. يجب على البرنامج التأكد من أن النقطة التي تستجيب للطلب هي المزود المتوقع.
على سبيل المثال، قد يستخدم المشغلون خدمة توقيع عن بُعد بدلاً من الاحتفاظ بعمليات التوقيع داخل نفس العملية. وقد يعتمد البعض على نقاط نهاية خارجية لتوفير البيانات أو خدمات بناء الكتل.
الضرر الذي يمكن أن يسببه المُزَيِّفون يعتمد على ما يُسمح للخدمة بفعله. الخدمة التي تتلقى فقط بيانات المراقبة تختلف في المخاطر عن الخدمة التي تشارك في اتخاذ قرارات التوقيع.
المسار الشبكي مهم بنفس القدر. فإن الاتصالات التي تمر عبر البنية التحتية العامة تختلف في فرص التنصت مقارنة بالعناصر المحدودة على نفس المضيف أو الشبكة الخاصة الخاضعة لسيطرة صارمة.
لا يمكن للشبكة الخاصة أن تمنع جميع الأعطال، لكنها يمكن أن تقلل من فرص المهاجمين للحصول على المواقع اللازمة لتعطيل الحركة.
لذلك، لا يمكن تحديد ما إذا كان هناك تعرض بناءً على اسم العميل فقط. يمكن توزيع نفس البرنامج في بيئات تستخدم نقاط نهاية ومخازن ثقة وتحكم في الوصول مختلفة.
السؤال الحقيقي الذي يجب الإجابة عنه هو: أي اتصال عبر مسارًا متأثرًا قبل قبول الشهادة. بمجرد تحديد ذلك، يمكن للمشغل تقييم الصلاحيات التي كان ينبغي أن تمتلكها الخدمة المُزَوَّرة ضمن عمل المُحقق.
لماذا تختلف صور Docker والتثبيت عبر الأرشيف؟
تُعبّأ صور Docker التطبيق والبيئة المطلوبة لتشغيله معًا، وقد تشمل وقت تشغيل Java والشهادات التي يثق بها هذا الوقت.
تحديث Java على المضيف لا يستبدل تلقائيًا Java الموجود في الصورة الحالية. قد تستمر الحاويات في استخدام الملفات المضمنة الخاصة بها.
هذا هو السبب الذي يجعل ملاحظات إصدار العميل تذكر بشكل خاص تغييرات Docker. وذكرت ملاحظات Teku أن صورتها الأساسية Eclipse Temurin لم تتضمن وقتها الإزالة ذات الصلة، لذا تم تعديل صورة العميل مباشرة.
كما أشارت ملاحظات إصدار Besu إلى أن إزالة الشهادة تنطبق على صور Docker، وطلبت صراحةً من المستخدمين الذين قاموا بالتثبيت يدويًا التحقق من إصدار Java الذي قدموه.
سيترك تثبيت الأرشيف هذه المسؤولية على عاتق المشغل. قد يكون عميل إيثريوم قد تم تحديثه، لكن وقت التشغيل المنفصل الخاص به قد يحتوي لا يزال على تخزين شهادات قديم.
على العكس، فإن عمليات الصيانة قد تُظهر فروقًا مشابهة. إن استبدال وقت تشغيل المضيف سيؤثر على العمليات التي تستخدم هذا الوقت، لكنه لن يؤثر على تثبيت آخر يستخدم مسار Java مختلف.
توصي حدث Oracle المستخدمين بتحديث التشغيليات المتأثرة أو اتباع البدائل المذكورة في وثائقها. كما تطلب إعادة تشغيل المثيلات الجارية، مع النظر في كل تثبيت مستقل على حدة.
هذا يجعل العمليات الجارية أكثر أهمية من التحديثات التي تم تنزيلها. يمكن للخادم أن يحتوي على ملفات مُصلحة، لكن العمليات القديمة ستستمر في العمل حتى يتم استبدالها أو إعادة التشغيل.
تم إضافة تغيير آخر إلى تخزين الشهادات المخصصة. قد تستخدم منظمة ما مخزن شهادات مخصصًا للخدمات الخاصة بها، وليس فقط مخزن الشهادات المقدم افتراضيًا من Java.
المهمة الفعلية هي تحديد ما يستخدمه العميل حقًا. طريقة التثبيت وموقع التشغيل وتكوين الثقة تحدد معًا ما إذا كان الإصلاح المنشور قد وصل إلى الوصلة التي تحتاجه.
Differences in revocation checks across different applications
إلغاء التصريح يعني أن الشهادة لا ينبغي قبولها مرة أخرى. لكن هذا لا يضمن أن كل تطبيق سيتحقق من أحدث معلومات الإلغاء قبل إنشاء الاتصال.
تختلف طرق الحصول على هذه المعلومات حسب التطبيق. بعضها يستفسر عن خدمات عبر الإنترنت، وبعضها يستخدم قوائم حظر مقدمة من الموردين، بينما يعتمد البعض الآخر بشكل رئيسي على الشهادات الموجودة في مكتبة الثقة المحلية.
أوضح فريق Go سبب حاجته لتدخل الموردين التشغيليين مباشرة. وقد أطلق الفريق إصدارًا أمنيًا عاجلًا في 19 أكتوبر، وأفاد بأن النسخة المُصلحة تم توفيرها بعد حوالي 7.5 ساعة من تلقي الإشعار.
هذا الإجراء يمنع مسارات الشهادات المتأثرة المستخدمة في التطبيقات التي تعتمد على سلوك التحقق Go. يحتاج مستخدمو Java إلى الحصول على الحماية من خلال إعدادات التشغيل والثقة الخاصة بهم.
أبلغ Teku أن Java لا تتحقق افتراضيًا من الإلغاء. وهذا هو السبب في أنه حتى بعد إلغاء eMudhra لهذه الشهادات الوسيطة، لا يزال من الضروري إزالة الثقة محليًا.
إزالة الشهادة الجذرية وحظر الشهادات الوسيطة قد تعمل أيضًا على مستويات مختلفة.前者 ترفض مسارًا تالفًا محددًا، بينما后者 يمكنه رفض سلسلة الشهادات الأشمل التي تؤدي إلى الشهادة الجذرية التي تم إزالتها.
التنفيذ الصحيح يقع على عاتق المورّد والمنظمة المسؤولة عن صيانة التطبيق. إن اعتماد مؤقت لتعطيل مصادقة الهوية لا يزيل الحماية فحسب، بل لا يحل مشكلة الثقة.
قد تحتاج الخدمات القانونية أيضًا إلى تعديل. إذا كانت شهاداتها تعتمد على مسار يرفضه العميل الآن، فعليها توفير بديل مقبول، بدلاً من الاعتماد على المستخدمين لاستعادة الثقة غير الآمنة.
وهذا يفسر لماذا يمكن أن تستمر حادثة الشهادة لعدة أيام. قد يكون الكشف فوريًا، لكن الحماية تُطبق تدريجيًا عبر عمليات النشر والصيانة المختلفة للمتصفحات، والتطبيقات المعبأة، والبنية التحتية الخاصة.
بالنسبة لمشغلي المُصادقين، فإن النتيجة الرئيسية هي ما إذا كانت الاتصالات ذات الصلة قد رفضت الهويات غير الموثوقة. لا تُثبت إشعارات الإلغاء في أجزاء أخرى من بيئة البرنامج أن عملية العقد قد حققت هذه النتيجة.
هل يتم تعريض المكافآت ورهان المُحققين بنفس الطريقة؟
تتعلق مسؤوليات راسمال المُصادق، والتوقيع، ودفع الرسوم ببعضها البعض، لكنها تخضع لآليات مختلفة. لا ينبغي وصف أي مشكلة تؤثر على أحد هذه الجوانب على أنها تحكم تلقائي في جميعها.
وثائق التخزين المضمون لإيثريوم: يحصل المُحققون على مكافآت من خلال الوفاء بواجباتهم، ويُعاقبون بسبب الانقطاع أو السلوك غير المناسب القابل للإثبات. تلعب صلاحيات التوقيع وصلاحيات السحب أدوارًا مختلفة في النظام.
مفتاح الشهادة ينتمي إلى نظام الهوية المستخدم للاتصال. إنه ليس المفتاح الخاص التوقيعي للمُحقق، ولا يُفصح مباشرة عن بيانات الاعتماد الخاصة بسحب ETH المُرتهنة.
ومع ذلك، قد تؤثر الخدمة المُزيفة لا يزال على سلوك المُحققين. يعتمد هذا التأثير على نوع الطلبات أو الاستجابات التي تتعامل معها الخدمة، وما إذا كانت لا تزال تُجري فحوصات إضافية.
يحتوي اقتراح الكتلة على جهة استلام الرسوم المرتبطة بالتنفيذ. إذا كان بإمكان مسار ما تعديل الاقتراح أو التكوين، فقد يؤدي ذلك إلى عواقب دون السيطرة على كامل الرهان.
خدمة التوقيع طرحت مجموعة أخرى من المشكلات لأنها تشارك في التحقق من سلوك المُصادقين. تؤثر تدابير الحماية الخاصة بها، بما في ذلك القيود المفروضة على الطلبات وضمانات منع التوقيعات المتعارضة، على مدى ما يمكن للمهاجمين تحقيقه.
إن تجاهل المهام الناتج عن انقطاع الخدمة هو أيضًا عواقب محتملة. حتى لو لم يُنقَل أي دفع بنجاح، يمكن للمهاجم تقليل المكافآت فقط بمنع الاستجابة الصحيحة.
التأثيرات المالية لهذه النتائج ليست متماثلة. لا يمكن الخلط بين ضياع فرصة اقتراح كتلة، والعقوبات العادية للانفصال، وعقوبات التخفيض.
يصف إشعار العميل العواقب المحتملة تحت التكوين المتأثر، لكنه لا يثبت أن كل مشغل تعرض لهذه العواقب، ولا يثبت سرقة كمية معينة من ETH.
بالنسبة للمالكين الذين يستخدمون مزودي الرهن، فإن ما يهم حقًا هو النشر الفعلي للمزود. عدد ETH الذي يتم إدارته لا يوضح أي خدمات عن بُعد أو مكتبات شهادات يستخدمها مشغلوه.
يُعتمد المُحققون أيضًا على برامج خارج إيثريوم
قواعد شبكة إيثريوم هي فقط جزء من الاعتماد الذي يعتمد عليه المشغلون. ستؤثر الأجهزة ووقت التشغيل والاستضافة والتكوين والخدمات الخارجية على قدرة المُحقق على الوفاء بواجباته بشكل صحيح.
توجد هيئة إصدار الشهادات خارج بروتوكول الإيثيريوم، لكن عندما تعتمد برامج المُحققين عليها لتحديد الخدمات، يصبح خللها ذا صلة. فقط هذا الأمر كافٍ لإدخال مشكلة أمان عامة على الإنترنت إلى بنية التخزين.
لا يزال تنوع العميل ذا قيمة، لأن التحقيقات المختلفة يمكن أن تقلل الاعتماد على قاعدة كود واحدة. لكن هذا لا يعني أن كل تبعية مستقلة.
يمكن لعميلين استخدام نفس بيئة تشغيل لغة البرمجة. قد يستخدم مقدمو خدمات مختلفون نفس مزود الاستضافة أو خدمة التوقيع أو بنية تحتية لبناء الكتل.
ستشكل هذه المكونات المشتركة سطحًا مشتركًا معرضًا للخطر في حالات مختلفة لبرنامج إيثريوم. لذلك، لا يمكن فهم حالة النشر بناءً على عدد علامات العميل فقط.
الاستعانة بمصادر خارجية تجلب أيضًا توازنات. قد تحسن خدمة التوقيع المخصصة طريقة حماية المفاتيح، لكنها تجعل الاتصالات المعتمدة مع هذه الخدمة أكثر أهمية.
التشغيل المحلي يتطلب أيضًا متطلبات صيانة خاصة. وضع المكونات على نفس الجهاز يمكن أن يقلل من بعض التعرض للشبكة، لكن المشغلين لا يزالون بحاجة إلى إدارة تحديثات البرنامج والوصول إلى ذلك الجهاز.
لا تُنتج هذه الحادثة تلقائيًا هيكلًا الأكثر أمانًا في جميع الظروف. بل توضح ضرورة فهم والحفاظ على مسؤوليات كل اتصال محيط.
هذا الفرق مهم أيضًا للمستخدمين العاديين لـ ETH. تطبيق التصحيحات على بنية العقد لا يعني أن كل محفظة يجب أن تنقل أموالها، ولا يعني أن أرصدة حسابات الإيثيريوم تغيرت.
الإجراءات ذات الصلة تقع على عاتق مشغلي البرنامج المتأثر. فقط هم قادرون على تحديد وقت التشغيل والنقاط النهائية وإعدادات الثقة المعنية، ثم تطبيق الإرشادات ذات الصلة من المورد على الأنظمة التي تنشئ هذه الاتصالات.
يجب على المشغلين تطبيق والتحقق من التحديثات
توفر هذه الإصدارات للمشغلين وسيلة لإزالة مسارات الثقة المتأثرة من صور Docker المدعومة. أما المستخدمون المُؤرخون، فيجب عليهم معالجة بيئات التشغيل المنفصلة وفقًا لإرشادات مزودي Java الخاصين بهم.
التوفر التصحيحي هو مجرد خطوة أولى في العملية. يجب أن يعمل البيئة المحدثة فعليًا وتحافظ على التكوين والخدمات المتوقعة بشكل طبيعي.
للمزودين للخدمات، قد يتطلب التعافي من الانقطاع الناتج عن شهادات مرفوضة حديثًا تغيير الشهادات على النقاط النهائية. يجب الحفاظ على التحقق من الهوية أثناء استعادة الخدمة، وليس تجاوزه.
قد تُفصّل الإفصاحات المستقبلية التأثيرات بشكل أدق. قد يُحدّد المشغلون تكوينًا تلقى سلسلة الشهادات المتأثرة، أو يبلغون عن أحداث تتعلق بخدمات محددة.
حاليًا، لم تُستغل تقارير الإشعارات الخاصة بـ Teku، وتم التمييز بين الاستخدام الافتراضي للشبكة الرئيسية والاتصالات الخارجية المتأثرة. هذا هو أوضح دليل متاح لوصف سطح الهجوم الحالي لإيثريوم.
المُشغلون المتأثرون لديهم أسباب للتحديث. أي خسائر مالية تعتمد على الخدمة التي انتحلها المهاجم، وما إذا كان قد اعتراض الحركة المرورية، وما إذا كان المُحققون يسمحون لهذه الخدمة بالقيام بذلك.
ما الذي يجب الانتباه إليه؟
- تحديث العميل: راقب إصدارات Teku و Besu وتأكد من تشغيل الإصدار المُصلح.
- شهادة Java: راجع إرشادات المورد لتحديد وقت التشغيل ومخزن الشهادات المستخدمين في كل تثبيت.
- روابط خارجية: مراجعة روابط HTTPS الموجهة إلى خدمات التوقيع البعيد والبيانات وبناء الكتل.
- إشعار أمان: كن حذرًا من التأكيدات أو التوضيحات الإضافية الصادرة عن فريق العميل ومزود Java.
أسئلة شائعة
ما هي حادثة eMudhra؟
تتضمن هذه الحادثة مفتاحًا خاصًا ضعيفًا مرتبطًا بشهادة وسطية من جهة إصدار الشهادات eMudhra. وجد الباحثون أن هذه المفاتيح يمكن استعادتها من معلومات عامة، مما قد يسمح للآخرين بإنشاء شهادات ل домينات لا يتحكمون بها. قد تقبل البرامج التي تثق بمسار الشهادة المتأثر هذا الهوية المزيفة. لا يزال المهاجمون بحاجة إلى طريقة ما لاعتراض أو إعادة توجيه الاتصالات للاستيلاء على خدمة الهدف.
هل فشل توافق إيثريوم؟
لا. تتعلق المشكلات المذكورة في التقرير بكيفية قيام البرنامج بالتحقق من هوية الخدمات الخارجية، وليس بقواعد الإجماع الخاصة بالإيثيريوم على البلوكشين. إن تحديثات العميل تغير ثقة الشهادات في بيئة البرنامج المتأثرة. قد لا تزال بعض نشرات المُحققين معرضة لمخاطر تشغيلية في حال تم التزوير على الخدمات الخارجية. تعتمد هذه الإمكانية على الاتصال ودور الخدمة، ولا تعني أن قواعد إجماع الإيثيريوم قد تم اختراقها.
Which clients have been updated?
قمت Teku 26.10.3 و Besu 26.10.2 بتعديل صور Docker الخاصة بهما لإزالة شهادات الثقة المتأثرة. Teku هو عميل التوافق، وBesu هو عميل التنفيذ، وكلاهما يستخدم Java. الطريقة التي يتم بها التثبيت مهمة، لأن هذا التغيير ينطبق على البيئات المقدمة ضمن هذه الصور. يجب على المشغلين الذين يقومون بتثبيت أرشيفات العميل وتقديم وقت تشغيل Java الخاص بهم، مراجعة الإرشادات الخاصة بوقت التشغيل هذا بشكل منفصل.
Will all validators be affected?
لا. أبلغت Teku أن العقد الافتراضي للشبكة الرئيسية غير متأثر. يعتمد الخطر على ما إذا كان التوزيع المعني أجرى اتصالات HTTPS خارجية ذات صلة، وما إذا كان فحص الشهادات الخاص به يقبل مسار الثقة المتأثر. يمكن للمنشئين المختلفين تشغيل نفس العميل تحت خدمات مختلفة، وإصدارات Java، ومكتبات شهادات مختلفة. وبالتالي، فإن اسم العميل أو عدد ETH المُرَهَّن لا يُظهران ما إذا كان مُحقق معين معرّض للخطر أم لا.
هل يمكن لتحديث Docker تغطية جميع طرق التثبيت؟
لا. يُحدث صورة Docker المُصْلَحة البيئة المُضمنة داخل الصورة، لكن التثبيت المُؤرشف قد يستخدم Java مقدمة من قبل المشغل. قد تحتوي حاويات أو خدمات أخرى على وقت تشغيل خاص بها. يجب على المشغل تحديد نوع التثبيت المستخدم من قبل العمليات الجارية والالتزام بإرشادات المورد. لا تحمي الملفات المُصلَحة على الخادم العمليات التي لا تزال تعمل في بيئة قديمة.
هل تم التأكيد على الاستغلال؟
في النقطة الزمنية المذكورة في هذه المقالة، لم تُبلغ إشعارات Teku عن أي استغلال. الوصف المقدم في الإفصاح يتعلق بضعف محتمل وعواقبه، وليس بإثبات أن المهاجمين قد استخدموه لصالح المُحققين. هذا التمييز مهم عند مناقشة الخسائر. وجود مسار محتمل للانتحال لا يعني أن مسؤوليات التوقيع قد تم التلاعب بها، أو أن مدفوعات الرسوم قد تم تحويلها، أو أن ETH المُرَهَّنة قد سُرقت.
Will validator deposits be automatically exposed?
لا. مفتاح توقيع الشهادة يختلف عن مفتاح توقيع المُحقق وعن صلاحية التحويل. استعادة مفتاح الشهادة المتأثر لا يكشف تلقائيًا المفاتيح المطلوبة لسحب ETH المُرَهَّنة. قد لا تزال الخدمة المُنتحَلة تخلّ بمسؤولياتها أو تؤثر على المعلومات التي يستخدمها المُحققون، حسب طريقة النشر. يجب تقييم العواقب المحتملة لهذه الخدمة، وليس اعتبارها وصولًا تلقائيًا إلى كامل الوديعة.
ما الذي ينبغي على المشغلين فعله؟
يجب على المشغلين اتباع إرشادات إصدارات Teku أو Besu ذات الصلة، بالإضافة إلى إرشادات إصدار Java الخاص بهم. يجب تحديد وقت التشغيل ومكتبة الشهادات المستخدمة من قبل كل عملية متأثرة، بما في ذلك المكونات المقدمة داخل الحاويات. بعد تطبيق التحديثات المقترحة، يجب التأكد من أن الخدمة المحدثة تعمل بشكل صحيح وأن الاتصالات المطلوبة لا تزال تعمل بشكل طبيعي. تعطيل فحص الشهادات من أجل استعادة الاتصالات الفاشلة يزيل الحماية التي كان ينبغي أن توفرها هذه الفحوصات.