تحديثات البث

نظرة عامة

أجهزة توجيه Java I2P وi2pd الأقدم من API 0.9.58 (تم إصدارها في مارس 2023) معرضة لهجوم إعادة تشغيل حزم SYN للبث. هذه مشكلة في تصميم البروتوكول، وليست خطأ في التنفيذ.

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

التصميم

الإصلاح يتطلب من أليس تضمين تجزئة وجهة بوب في بيانات الحزمة الموقعة SYN. بوب يتحقق عند الاستقبال من أن تلك التجزئة تتطابق مع تجزئته.

أي ضحية محتملة لهجوم، تشارلي، يفحص هذه البيانات ويرفض الحزمة SYN إذا لم تطابق تجزئته.

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

جميع الخيارات مغطاة بالتوقيع، كالمعتاد، لذلك لا يمكن لبوب إعادة كتابة التجزئة.

إذا كانت أليس وتشارلي تستخدمان API 0.9.58 أو أحدث، فسيتم رفض أي محاولة إعادة تشغيل بواسطة بوب.

المواصفات

تحديث مواصفات Streaming لإضافة القسم التالي:

منع إعادة التشغيل

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

.. raw:: html

{% highlight lang=‘dataspec’ %} Set NACK count field to 8 Set the NACKs field to Bob’s 32-byte destination hash

{% endhighlight %}

عند استلام الحزمة SYNC، إذا كان حقل عدد NACK هو 8، يجب على بوب تفسير حقل NACKs كتجزئة وجهة 32-بايت، ويجب أن يتحقق من أنها تتطابق مع تجزئة وجهته. يجب عليه أيضًا التحقق من توقيع الحزمة كالمعتاد، لأن ذلك يغطي الحزمة بأكملها بما في ذلك حقلي NACK count وNACKs. إذا كان عدد NACK هو 8 ولم يطابق حقل NACKs، يجب على بوب أن يسقط الحزمة.

هذا مطلوب للإصدارات 0.9.58 والأعلى. هذا متوافق مع الإصدارات السابقة، لأن NACKs غير متوقعة في حزمة SYNC. الوجهات لا تعرف ولا يمكنها معرفة أي إصدار يعمل عليه الطرف الآخر.

لا ضرورة لتغيير حزمة SYNC ACK المرسلة من بوب إلى أليس؛ لا تقم بتضمين NACKs في تلك الحزمة.

تحليل الأمان

كانت هذه القضية موجودة في بروتوكول البث منذ إنشائه في 2004. تم اكتشافها داخليًا بواسطة مطوري I2P. ليس لدينا دليل على أن القضية قد تم استغلالها في أي وقت. قد يختلف احتمال نجاح الاستغلال بشكل واسع اعتمادًا على بروتوكول الطبقة التطبيقية والخدمة. التطبيقات النظير-إلى-النظير قد تكون أكثر عرضة للتأثر من تطبيقات العميل/الخادم.

التوافق

لا توجد مشاكل. جميع التطبيقات المعروفة حاليًا تتجاهل حقل NACKs في حزمة SYN. وحتى إذا لم يتجاهلوه، وحاولوا تفسيره كـ NACKs لـ8 رسائل مختلفة، فلن تكون تلك الرسائل معلقة خلال المصافحة SYN ولن يكون لـ NACKs أي معنى.

الهجرة

يمكن للتطبيقات إضافة الدعم في أي وقت، ولا حاجة إلى التنسيق. قامت أجهزة توجيه Java I2P وi2pd بتنفيذ هذا في API 0.9.58 (تم إصدارها في مارس 2023).