Iron Fish: كيف يمكن لثغرة كُتبت عام 2019 أن توقف السلسلة بأكملها؟
نشر حساب Iron Fish الرسمي على X منشورًا مطولًا فجر 31 أكتوبر بتوقيت بكين: أنهى المشروع رسميًا في ذلك اليوم كل أشكال الدعم المتبقية لشبكة Iron Fish. وكان السبب صريحًا جدًا، ويمكنني تلخيصه في نقاط:
1. البداية: قبل بضعة أيام، رصدوا نشاطًا غير اعتيادي في wIRON وجسر ChainPort بين السلاسل. وبعد مراجعة السجلات مع ChainPort، تأكدوا أن أصل المشكلة ثغرة تضخيم (inflation) في سلسلة Iron Fish نفسها.
2. المصدر: تعود المشكلة إلى تغيير برمجي أُدخل في أوائل عام 2019 على تنفيذ شجرة Merkle. وبسبب تفصيل في طريقة حساب nullifier الخاص بـnote (علامة الإبطال التي يعتمد عليها المستخدم العادي عند إنفاق أمواله)، استطاع المهاجم إنفاق note نفسه أكثر من مرة.
3. الخروج: استغل المهاجم الثغرة مرارًا، ودمج الـnotes التي بحوزته، ثم غادر عبر جسر ChainPort بين السلاسل.
4. الختام: أُرسل التصحيح، وأُرفق تقرير مفصل لما بعد الحادثة في طلب السحب (PR)، ثم أُوقفت مستودعات الشيفرة وأُرشفت.
بعض الحقائق الصريحة:
· أكثر ما يوجع في الأمر: كانت هذه الشيفرة ضمن نطاق التدقيق الداخلي والخارجي، لكن المراجعة لم تكشفها. «خضعت للتدقيق» لا تعني أبدًا «خالية من الثغرات».
· لم يذكر المنشور الرسمي المطول حجم الخسائر. لا تصدقوا الأرقام المتداولة على الإنترنت حاليًا، ولن أقدّرها من عندي.
· ظلّت ثغرة تتيح «إنفاق المال نفسه أكثر من مرة» كامنة لسنوات، ويصعب على الغرباء ملاحظتها من النظرة الأولى على سلسلة مصممة للخصوصية. لكن هذا لا يعني أن «سلاسل الخصوصية كلها غير آمنة»، فلا تستنتجوا ذلك من عندكم.
· تأملات Iron Fish (وهذا رأي فريق المشروع): البرمجيات التي لا يمكن ترقيتها فورًا — أي معظم البرمجيات المشفرة — تواجه وضعًا خطيرًا للغاية؛ فالعثور على الثغرات واستغلالها أصبح أقل كلفة، وقد لا يتمكن الطرف الذي يصلحها من مواكبة ذلك.
هل يستطيع المشروع الذي تحتفظ به إصدار تصحيح بسرعة بعد وقوع مشكلة؟ أم أن يوم إصدار التصحيح سيكون، كما في هذه الحالة، يوم إغلاق المشروع؟
#IronFish #隐私链 #التدقيق_الأمني
نشر حساب Iron Fish الرسمي على X منشورًا مطولًا فجر 31 أكتوبر بتوقيت بكين: أنهى المشروع رسميًا في ذلك اليوم كل أشكال الدعم المتبقية لشبكة Iron Fish. وكان السبب صريحًا جدًا، ويمكنني تلخيصه في نقاط:
1. البداية: قبل بضعة أيام، رصدوا نشاطًا غير اعتيادي في wIRON وجسر ChainPort بين السلاسل. وبعد مراجعة السجلات مع ChainPort، تأكدوا أن أصل المشكلة ثغرة تضخيم (inflation) في سلسلة Iron Fish نفسها.
2. المصدر: تعود المشكلة إلى تغيير برمجي أُدخل في أوائل عام 2019 على تنفيذ شجرة Merkle. وبسبب تفصيل في طريقة حساب nullifier الخاص بـnote (علامة الإبطال التي يعتمد عليها المستخدم العادي عند إنفاق أمواله)، استطاع المهاجم إنفاق note نفسه أكثر من مرة.
3. الخروج: استغل المهاجم الثغرة مرارًا، ودمج الـnotes التي بحوزته، ثم غادر عبر جسر ChainPort بين السلاسل.
4. الختام: أُرسل التصحيح، وأُرفق تقرير مفصل لما بعد الحادثة في طلب السحب (PR)، ثم أُوقفت مستودعات الشيفرة وأُرشفت.
بعض الحقائق الصريحة:
· أكثر ما يوجع في الأمر: كانت هذه الشيفرة ضمن نطاق التدقيق الداخلي والخارجي، لكن المراجعة لم تكشفها. «خضعت للتدقيق» لا تعني أبدًا «خالية من الثغرات».
· لم يذكر المنشور الرسمي المطول حجم الخسائر. لا تصدقوا الأرقام المتداولة على الإنترنت حاليًا، ولن أقدّرها من عندي.
· ظلّت ثغرة تتيح «إنفاق المال نفسه أكثر من مرة» كامنة لسنوات، ويصعب على الغرباء ملاحظتها من النظرة الأولى على سلسلة مصممة للخصوصية. لكن هذا لا يعني أن «سلاسل الخصوصية كلها غير آمنة»، فلا تستنتجوا ذلك من عندكم.
· تأملات Iron Fish (وهذا رأي فريق المشروع): البرمجيات التي لا يمكن ترقيتها فورًا — أي معظم البرمجيات المشفرة — تواجه وضعًا خطيرًا للغاية؛ فالعثور على الثغرات واستغلالها أصبح أقل كلفة، وقد لا يتمكن الطرف الذي يصلحها من مواكبة ذلك.
هل يستطيع المشروع الذي تحتفظ به إصدار تصحيح بسرعة بعد وقوع مشكلة؟ أم أن يوم إصدار التصحيح سيكون، كما في هذه الحالة، يوم إغلاق المشروع؟
#IronFish #隐私链 #التدقيق_الأمني
