خلال الأيام القليلة الماضية حلّلتُ الأمان الخاصة بـ AEGIS بخصوص @Dusk . في البداية حفظت فقط “39 إصلاحًا و7 حرِجة”. لكن بعد قراءة التفاصيل أدركت أن الأرقام الكبيرة ليست هي النقطة الأساسية. في النهاية تقلّصت 7 مشكلات خطيرة إلى 4 فئات من الأسباب الجذرية: مشكلة الأسماء المستعارة داخل VM Sandbox، عدم الأمان في إلغاء التسلسل من جهة المضيف، عدم وجود ربط كامل بين رسوم Phoenix والمبالغ المستردة، ومسار تزوير توقيعات BLS.
لماذا نُركّز على الأسباب الجذرية وليس فقط على عدد الثغرات؟ لأن نفس حدود الثقة عندما لا تُرسم جيدًا قد يتكرر ظهور المشكلات في وحدات مختلفة. مثلًا، إذا لم يتم التحقق من الإدخال قبل إلغاء التسلسل، فقد يبدو الأمر كأنه خطأ تحليل مرة واحدة على السطح، لكنه قد يؤدي فعليًا إلى مشاكل أمان في ذاكرة المضيف. ومشكلات مجموعة Phoenix ليست “مجرد حساب الرسوم بشكل خاطئ قليلًا”، بل هي أن الإثبات والتوقيع وتنفيذ المبالغ المستردة لا يتبعون نفس الدلالة (الـ semantics). والأسوأ قد يصطدم بمسائل سلامة التوريد وتوفير الأمان المالي.
يقول المصدر الرسمي إنه لم يتم العثور على استغلال لهذه الـ critical قبل إصلاحها حاليًا. وأنا أرغب في اعتبار ذلك نتيجة تحقيق ولا أحوّلها إلى “لم يحدث أبدًا”. وبالنسبة إلى $DUSK ، فإن الإشارة الإيجابية لدى AEGIS هي أن الفريق نشر اكتشافات داخلية إلى مستوى الأسباب الجذرية ومنطق الإصلاح. والإشارة السلبية واضحة أيضًا: بعد الإطلاق على الشبكة الرئيسية، ظهرت فجوات عالية الخطورة فعلًا يمكن أن تؤثر في التنفيذ والتحقق من الإجماع وإتاحة السلسلة.
لذلك لن أستخدم عبارة “تم تدقيقه كثيرًا” كختم أمان مباشر لـ #dusk . والأكثر فائدة في الملاحظة هو: هل ستستمر الجولة القادمة في الكشف؟ وهل توجد اختبارات رجعية لحدود مماثلة؟ وهل يمكن للجهات المدققة الخارجية تغطية الكود بعد AEGIS؟ أنتم—هل تهتمون أكثر بأن المشروع لم يُكشف عنه أبدًا عن مشكلات كبيرة، أم بأن يتم الكشف عنها لاحقًا بحيث تُشرح الأسباب الجذرية والأثر وسلسلة الإصلاح بوضوح؟
$USELESS $BOME
لماذا نُركّز على الأسباب الجذرية وليس فقط على عدد الثغرات؟ لأن نفس حدود الثقة عندما لا تُرسم جيدًا قد يتكرر ظهور المشكلات في وحدات مختلفة. مثلًا، إذا لم يتم التحقق من الإدخال قبل إلغاء التسلسل، فقد يبدو الأمر كأنه خطأ تحليل مرة واحدة على السطح، لكنه قد يؤدي فعليًا إلى مشاكل أمان في ذاكرة المضيف. ومشكلات مجموعة Phoenix ليست “مجرد حساب الرسوم بشكل خاطئ قليلًا”، بل هي أن الإثبات والتوقيع وتنفيذ المبالغ المستردة لا يتبعون نفس الدلالة (الـ semantics). والأسوأ قد يصطدم بمسائل سلامة التوريد وتوفير الأمان المالي.
يقول المصدر الرسمي إنه لم يتم العثور على استغلال لهذه الـ critical قبل إصلاحها حاليًا. وأنا أرغب في اعتبار ذلك نتيجة تحقيق ولا أحوّلها إلى “لم يحدث أبدًا”. وبالنسبة إلى $DUSK ، فإن الإشارة الإيجابية لدى AEGIS هي أن الفريق نشر اكتشافات داخلية إلى مستوى الأسباب الجذرية ومنطق الإصلاح. والإشارة السلبية واضحة أيضًا: بعد الإطلاق على الشبكة الرئيسية، ظهرت فجوات عالية الخطورة فعلًا يمكن أن تؤثر في التنفيذ والتحقق من الإجماع وإتاحة السلسلة.
لذلك لن أستخدم عبارة “تم تدقيقه كثيرًا” كختم أمان مباشر لـ #dusk . والأكثر فائدة في الملاحظة هو: هل ستستمر الجولة القادمة في الكشف؟ وهل توجد اختبارات رجعية لحدود مماثلة؟ وهل يمكن للجهات المدققة الخارجية تغطية الكود بعد AEGIS؟ أنتم—هل تهتمون أكثر بأن المشروع لم يُكشف عنه أبدًا عن مشكلات كبيرة، أم بأن يتم الكشف عنها لاحقًا بحيث تُشرح الأسباب الجذرية والأثر وسلسلة الإصلاح بوضوح؟
$USELESS $BOME
