أكد فريق تطوير Bitcoin Core في 12 يونيو عبر منصة X أن ميزة -privatebroadcast التي تم إدخالها حديثًا في الإصدار 31.0 من Bitcoin Core تحتوي على ثغرة خصوصية: في ظل ظروف شبكة معيّنة، إذا فشل مصافحة v2، فسيتم الاتصال بعُقد نظيرة عبر IPv4 أو IPv6، ما يؤدي إلى كشف عنوان IP في الشبكة العامة للمرسل إلى الجهة المستلمة.
شروط المستخدمين المتأثرين: خمس نقاط يجب أن تتوافر معًا
ووفقًا للإعلان الرسمي من Bitcoin Core، لا تتعرض العقدة لهذه الثغرة إلا عند تحقق جميع الشروط الخمس التالية في آن واحد:
· تشغيل Bitcoin Core 31.0 على العقدة، وتمكين ميزة -privatebroadcast
· يتم بث المعاملات عبر أمر RPC sendrawtransaction (لا تستخدم واجهات RPC الخاصة بالمحافظ مثل sendtoaddress أو sendall البث الخاص، وبالتالي لا تتأثر)
يمكن لـ Tor إنشاء اتصالات صادرة
· يمكنها مباشرة إنشاء اتصالات صادرة عبر IPv4 أو IPv6 (لا توجد قيود -onlynet، ولا توجد إعدادات -proxy=...)
· لم يتم تعطيل نقل BIP324 v2 (لم يتم تعيين -v2transport=0)
لا تتأثر الاتصالات بعُقد نظيرة على onion وI2P، لأن أي إعادة محاولة ضمن v1 تتم دائمًا عبر مساراتها الوكيلة الخاصة بها.
الآلية التقنية للثغرة: عند فشل مصافحة v2 لا تُجرى إعادة المحاولة عبر Tor
وفقًا لشرح رسمي، فإن آلية تشغيل الثغرة تكون كالتالي: عندما تختار البث الخاص عقد نظيرة عبر IPv4 أو IPv6 تدعم نقل v2 (BIP324)، يتم إنشاء اتصال مبدئي كما هو متوقع عبر مسار وكيل Tor. إذا فشلت مصافحة v2، سيحاول Bitcoin Core إعادة المحاولة باستخدام بروتوكول v1، وهذه إعادة المحاولة عبر v1 لا تتم عبر مسار وكيل Tor، بل يتم الاتصال مباشرة عبر IPv4 أو IPv6، ما يؤدي إلى تسريب عنوان IP الخاص بالمُطلق.
يُخالف ذلك ضمان الخصوصية المذكور في إرشادات الإصدار 31.0: «لن يعرف المتلقّي أبدًا عنوان IP (وكذلك موقعه الجغرافي)». أكد فريق التطوير أن هذه الثغرة من المرجح جدًا أن تُحفّز بشكل متعمد عبر عُقد نظيرة خبيثة من خلال إغلاق مصافحة v2 عمدًا لفرض إعادة محاولة v1.
ثلاث حلول مؤقتة: يمكن تطبيقها قبل الترقية إلى 31.1
قدّم Bitcoin Core الرسمي الخيارات الثلاثة التالية كحلول مؤقتة:
الخيار الأول (موصى به): قم بتعطيل إعداد -privatebroadcast مباشرةً عبر -privatebroadcast=0
الخيار الثاني: تعطيل نقل v2 عبر -v2transport=0. انتبه: سيؤدي هذا الإعداد إلى أن تستخدم العقدة جميع الاتصالات ببروتوكول v1 غير مُشفّر، ما يجعلها أكثر عرضة للتمييز بالبصمة على الشبكة العامة وللتعرّض للملاحقة.
الخيار الثالث: توجيه حركة البيانات الصادرة عبر IPv4/IPv6 إلى Tor عبر -proxy=127.0.0.1:9050 (استبدلها بمنفذ SOCKS الفعلي الخاص بـ Tor). انتبه: سيجعل هذا الإعداد العقدة أكثر عرضة لهجمات الطُعمات (Sybil Attack).
الأسئلة الشائعة
هل العقد التي تستخدم RPC للمحافظ مثل sendtoaddress أو sendall متأثرة؟
وفقًا للإعلان الرسمي من Bitcoin Core، لا تستخدم RPC الخاصة بالمحافظ (مثل sendtoaddress وsendall وغيرها) ميزة البث الخاص، وبالتالي لا تتأثر بهذه الثغرة. لا يتم تشغيل هذه الثغرة إلا عند البث عبر sendrawtransaction واستيفاء الشروط الأربعة الأخرى.
هل يمكن أن تحدث هذه الثغرة تلقائيًا دون الحاجة إلى عقد نظيرة خبيثة؟
وفقًا للشرح الرسمي، بالنسبة لعُقد نظيرة تدعم نقل v2 فعليًا، فمن غير المحتمل أن تفشل مصافحة v2 في الظروف العادية. ومن المرجح جدًا أن يتم تحفيز الثغرة يدويًا عبر إيقاف مصافحة v2 عمدًا بواسطة عُقد نظيرة خبيثة لفرض إعادة محاولة v1.
ما هو جدول الإصدار الخاص بـ Bitcoin Core 31.1؟
وفقًا للإعلان الرسمي من Bitcoin Core، سيتم إصدار حل الإصلاح مع إصدار 31.1، لكن الإعلان لم يقدم تاريخ إصدار محدد. توصي الجهة الرسمية بالاعتماد على أحد الحلول الثلاثة المؤقتة المذكورة أعلاه قبل الترقية إلى 31.1.
