#XRPLedgerPatchesXRPCreationBug
لا تعني محدودية المعروض شيئًا إذا كان الرمز البرمجي الذي يفرضها قد يخطئ في الحساب.
كشف سجل XRP للتو عن ثغرة عمرها عقد من الزمن، كان من الممكن أن تتيح للمهاجمين إنشاء XRP قابل للإنفاق من لا شيء.
إليكم الجانب الذي أرى أنه يستحق مزيدًا من الاهتمام.
تعلّق الخلل بتجاوز سعة الأعداد الصحيحة في محرك الدفع. فمن خلال إنشاء مئات عروض التبادل المسعّرة عمدًا على نحو خاطئ، ثم استهلاكها جميعًا في دفعة واحدة، كان بإمكان المهاجم جعل النظام يضيف إلى أرصدة البائعين كمية من XRP تفوق بكثير ما دفعه المشتري فعليًا.
حتى فحص حماية المعروض المدمج في السجل كان من الممكن أن يفوّت هذا التفاوت، لأنه اعتمد على عمليات حسابية عرضة لتجاوز السعة نفسه.
عولجت الثغرة في xrpld 3.4.1، الذي صدر في 25 سبتمبر. ويقول المطورون إنهم لم يجدوا أي دليل على استغلالها في الشبكات العامة. لذا، لنكن دقيقين: كان هذا استغلالًا محتملاً بالغ الخطورة، وليس دليلًا على سرقة مليارات من XRP أو إنشائها فعليًا على الشبكة الحية.
ما الخلاصة الأهم بالنسبة إليّ؟ لا يقتصر أمان البلوك تشين على اللامركزية أو التشفير أو شفافية المعاملات، بل يعتمد أيضًا على صحة البرمجيات التي تعالج تلك المعاملات.
وهنا درس غير مريح: قد يضم النظام عدة فحوصات أمان، ومع ذلك يفشل إذا كانت هذه الفحوصات تشترك في الضعف الأساسي نفسه.
قد تساعد الأبحاث الأمنية المدعومة بالذكاء الاصطناعي في كشف هذه العيوب، لكن العثور على الثغرات ليس سوى نصف المعركة. لا يزال التحقق المستقل والاختبار الدقيق وسرعة إصدار التصحيحات والإفصاح المسؤول أمورًا بالغة الأهمية.
السؤال الحقيقي ليس ما إذا كانت الشبكة قد شهدت خللًا من قبل، بل ما إذا كانت إجراءاتها الأمنية قادرة على اكتشافه واحتوائه وإصلاحه قبل أن يستغله مهاجم.
هل غيّرت هذه الحادثة نظرتك إلى أمان سجل XRP، أم أن نجاح التصحيح عزز ثقتك به؟
#XRP
لا تعني محدودية المعروض شيئًا إذا كان الرمز البرمجي الذي يفرضها قد يخطئ في الحساب.
كشف سجل XRP للتو عن ثغرة عمرها عقد من الزمن، كان من الممكن أن تتيح للمهاجمين إنشاء XRP قابل للإنفاق من لا شيء.
إليكم الجانب الذي أرى أنه يستحق مزيدًا من الاهتمام.
تعلّق الخلل بتجاوز سعة الأعداد الصحيحة في محرك الدفع. فمن خلال إنشاء مئات عروض التبادل المسعّرة عمدًا على نحو خاطئ، ثم استهلاكها جميعًا في دفعة واحدة، كان بإمكان المهاجم جعل النظام يضيف إلى أرصدة البائعين كمية من XRP تفوق بكثير ما دفعه المشتري فعليًا.
حتى فحص حماية المعروض المدمج في السجل كان من الممكن أن يفوّت هذا التفاوت، لأنه اعتمد على عمليات حسابية عرضة لتجاوز السعة نفسه.
عولجت الثغرة في xrpld 3.4.1، الذي صدر في 25 سبتمبر. ويقول المطورون إنهم لم يجدوا أي دليل على استغلالها في الشبكات العامة. لذا، لنكن دقيقين: كان هذا استغلالًا محتملاً بالغ الخطورة، وليس دليلًا على سرقة مليارات من XRP أو إنشائها فعليًا على الشبكة الحية.
ما الخلاصة الأهم بالنسبة إليّ؟ لا يقتصر أمان البلوك تشين على اللامركزية أو التشفير أو شفافية المعاملات، بل يعتمد أيضًا على صحة البرمجيات التي تعالج تلك المعاملات.
وهنا درس غير مريح: قد يضم النظام عدة فحوصات أمان، ومع ذلك يفشل إذا كانت هذه الفحوصات تشترك في الضعف الأساسي نفسه.
قد تساعد الأبحاث الأمنية المدعومة بالذكاء الاصطناعي في كشف هذه العيوب، لكن العثور على الثغرات ليس سوى نصف المعركة. لا يزال التحقق المستقل والاختبار الدقيق وسرعة إصدار التصحيحات والإفصاح المسؤول أمورًا بالغة الأهمية.
السؤال الحقيقي ليس ما إذا كانت الشبكة قد شهدت خللًا من قبل، بل ما إذا كانت إجراءاتها الأمنية قادرة على اكتشافه واحتوائه وإصلاحه قبل أن يستغله مهاجم.
هل غيّرت هذه الحادثة نظرتك إلى أمان سجل XRP، أم أن نجاح التصحيح عزز ثقتك به؟
#XRP