ثغرة XRP «العشرية» تتصدر الأخبار: أُصدر التصحيح، وما ينبغي متابعته حقًا هو الفوارق الزمنية الثلاثة
إن عبارة «إمكانية إنشاء XRP من العدم» توحي بوقوع حادثة جارية. لكن لنضبط الساعة أولًا: ما كُشف علنًا في 9 أكتوبر هو الإفصاح عن الثغرة؛ أما إصلاح محرك المدفوعات فقد صدر سابقًا مع xrpld 3.4.1. وفي 10 أكتوبر، أتاح GitHub أيضًا الشيفرة المصدرية لهذا الإصدار وتعليمات الترقية. فالإفصاح، وإصلاح البرنامج، وتفعيل القواعد على الشبكة الرئيسية، يجيب كل منها عن سؤال مختلف.
أولًا، تؤثر ثغرة محرك المدفوعات في الإصدار 3.4.0 والإصدارات الأقدم. أبلغ باحثون عنها في 22 سبتمبر عبر برنامج مكافآت اكتشاف الثغرات، وبعد أن أعاد الفريق إنتاجها رفع درجة خطورتها، ثم أصدر إصلاحًا في 25 سبتمبر. ويرجح التحقيق الرسمي أن المشكلة تعود إلى شيفرة كُتبت عام 2015. ويفيد التقرير بأنه لم يُعثر على أدلة تثبت استغلال الثغرة في شبكة عامة؛ وهذا استنتاج للتحقيق، ولا يصح تعميمه بالقول إن جميع الأنشطة السابقة ثبت خلوها من المخالفات، فضلًا عن وصف الأمر مباشرةً بأنه هجوم لسكّ عملات إضافية.
ثانيًا، يتضمن التقرير نفسه مشكلة في التحقق من المعاملات الداخلية ضمن Batch. لم تكن هذه القاعدة مفعّلة على الشبكة الرئيسية عند اكتشافها. أُدرج الإصلاح أولًا في البرنامج، لكن تفعيل fixBatchV1_2 على الشبكة الرئيسية لم يحدث إلا في 9 أكتوبر؛ أما إصلاح محرك المدفوعات فدخل حيز التنفيذ فور ترقية العقد. والخلط بين مساري الإصلاح والقول إن «جميع الثغرات سُدّت فقط في 9 أكتوبر» يعطي صورة خاطئة عن نافذة المخاطر.
ثالثًا، ينبغي عدم الخلط بين ما يجب أن يفعله حاملو العملة العاديون وما يجب أن يفعله مشغلو العقد. يطلب GitHub حاليًا ترقية الخوادم إلى الإصدار 3.4.1، ويوضح أن الإصدارات القديمة مُنعت من العمل بسبب تعديل جديد، ولم يعد بإمكانها مواصلة المزامنة بصورة طبيعية. وينطبق طلب الترقية هنا على برامج الخوادم، ولا يعني أن على حاملي العملة نقل أصولهم إلى موقع مجهول «لإصلاح المحفظة». إذا صادفتم روابط تستغل أخبار الأمان لطلب عبارة الاسترداد أو الحصول على تفويض، فتحققوا أولًا من القنوات الرسمية.
ما استخلصه من هذه الحادثة هو أن الدفاع الأمني لا ينبغي أن يكرر الافتراض نفسه فحسب: فإذا كان ثمة خلل في حساب المدفوعات، فقد تفوته طبقة التحقق أيضًا إذا اعتمدت الافتراضات الحسابية نفسها. لذلك يستحق كل من التصحيح وإجراءات المراجعة اللاحقة المتابعة. وهذا استنتاج مستمد من آلية الإفصاح، وليس حكمًا على وجود ثغرات في بروتوكولات أخرى.
سأواصل متابعة ما إذا كانت الجهات الرسمية ستضيف نتائج للتحقيق، ومعدل ترقية العقد القديمة، وعمليات المراجعة الأمنية اللاحقة. فهذه الأمور قد تغيّر تقدير المخاطر التقنية؛ أما استمرار ارتفاع السعر، فيحتاج إلى أدلة من أحجام التداول والطلب الداعم. ولا يمكن استنتاج إشارة شراء من إصلاح ثغرة أمنية وحده.
المصادر: إفصاح XRPL الرسمي عن الثغرة في 9 أكتوبر، وملاحظات إصدار XRPLF/rippled 3.4.1. جرى التحقق في 10 أكتوبر، الساعة 22:36 بتوقيت بكين.
إن عبارة «إمكانية إنشاء XRP من العدم» توحي بوقوع حادثة جارية. لكن لنضبط الساعة أولًا: ما كُشف علنًا في 9 أكتوبر هو الإفصاح عن الثغرة؛ أما إصلاح محرك المدفوعات فقد صدر سابقًا مع xrpld 3.4.1. وفي 10 أكتوبر، أتاح GitHub أيضًا الشيفرة المصدرية لهذا الإصدار وتعليمات الترقية. فالإفصاح، وإصلاح البرنامج، وتفعيل القواعد على الشبكة الرئيسية، يجيب كل منها عن سؤال مختلف.
أولًا، تؤثر ثغرة محرك المدفوعات في الإصدار 3.4.0 والإصدارات الأقدم. أبلغ باحثون عنها في 22 سبتمبر عبر برنامج مكافآت اكتشاف الثغرات، وبعد أن أعاد الفريق إنتاجها رفع درجة خطورتها، ثم أصدر إصلاحًا في 25 سبتمبر. ويرجح التحقيق الرسمي أن المشكلة تعود إلى شيفرة كُتبت عام 2015. ويفيد التقرير بأنه لم يُعثر على أدلة تثبت استغلال الثغرة في شبكة عامة؛ وهذا استنتاج للتحقيق، ولا يصح تعميمه بالقول إن جميع الأنشطة السابقة ثبت خلوها من المخالفات، فضلًا عن وصف الأمر مباشرةً بأنه هجوم لسكّ عملات إضافية.
ثانيًا، يتضمن التقرير نفسه مشكلة في التحقق من المعاملات الداخلية ضمن Batch. لم تكن هذه القاعدة مفعّلة على الشبكة الرئيسية عند اكتشافها. أُدرج الإصلاح أولًا في البرنامج، لكن تفعيل fixBatchV1_2 على الشبكة الرئيسية لم يحدث إلا في 9 أكتوبر؛ أما إصلاح محرك المدفوعات فدخل حيز التنفيذ فور ترقية العقد. والخلط بين مساري الإصلاح والقول إن «جميع الثغرات سُدّت فقط في 9 أكتوبر» يعطي صورة خاطئة عن نافذة المخاطر.
ثالثًا، ينبغي عدم الخلط بين ما يجب أن يفعله حاملو العملة العاديون وما يجب أن يفعله مشغلو العقد. يطلب GitHub حاليًا ترقية الخوادم إلى الإصدار 3.4.1، ويوضح أن الإصدارات القديمة مُنعت من العمل بسبب تعديل جديد، ولم يعد بإمكانها مواصلة المزامنة بصورة طبيعية. وينطبق طلب الترقية هنا على برامج الخوادم، ولا يعني أن على حاملي العملة نقل أصولهم إلى موقع مجهول «لإصلاح المحفظة». إذا صادفتم روابط تستغل أخبار الأمان لطلب عبارة الاسترداد أو الحصول على تفويض، فتحققوا أولًا من القنوات الرسمية.
ما استخلصه من هذه الحادثة هو أن الدفاع الأمني لا ينبغي أن يكرر الافتراض نفسه فحسب: فإذا كان ثمة خلل في حساب المدفوعات، فقد تفوته طبقة التحقق أيضًا إذا اعتمدت الافتراضات الحسابية نفسها. لذلك يستحق كل من التصحيح وإجراءات المراجعة اللاحقة المتابعة. وهذا استنتاج مستمد من آلية الإفصاح، وليس حكمًا على وجود ثغرات في بروتوكولات أخرى.
سأواصل متابعة ما إذا كانت الجهات الرسمية ستضيف نتائج للتحقيق، ومعدل ترقية العقد القديمة، وعمليات المراجعة الأمنية اللاحقة. فهذه الأمور قد تغيّر تقدير المخاطر التقنية؛ أما استمرار ارتفاع السعر، فيحتاج إلى أدلة من أحجام التداول والطلب الداعم. ولا يمكن استنتاج إشارة شراء من إصلاح ثغرة أمنية وحده.
المصادر: إفصاح XRPL الرسمي عن الثغرة في 9 أكتوبر، وملاحظات إصدار XRPLF/rippled 3.4.1. جرى التحقق في 10 أكتوبر، الساعة 22:36 بتوقيت بكين.