تحليل ثغرات مترجم Solidity واستراتيجيات التعامل معها

المترجم هو أحد المكونات الأساسية في أنظمة الكمبيوتر الحديثة، وتتمثل وظيفته في تحويل كود المصدر بلغة البرمجة عالية المستوى إلى تعليمات قابلة للتنفيذ بواسطة الكمبيوتر. غالبًا ما يركز معظم المطورين وموظفي الأمن على أمان كود التطبيقات، لكنهم غالبًا ما يتجاهلون أمان المترجم نفسه. في الواقع، يمكن أن يحتوي المترجم، كبرنامج كمبيوتر، على ثغرات أمنية، مما قد يسبب مخاطر أمنية خطيرة في سيناريوهات معينة.

على سبيل المثال، عندما يقوم المتصفح بتجميع وتنفيذ كود JavaScript، قد يؤدي وجود ثغرات في محرك JavaScript إلى استغلالها من قبل المهاجمين عند زيارة المستخدم لمواقع الويب الضارة، مما يسمح بتنفيذ تعليمات برمجية عن بُعد والسيطرة في النهاية على متصفح الضحية أو حتى نظام التشغيل. كما أظهرت دراسة أخرى أن الأخطاء في مترجم C++ قد تؤدي إلى عواقب وخيمة مثل تنفيذ التعليمات البرمجية عن بُعد.

هناك أيضًا ثغرات أمنية في مترجم Solidity. وفقًا لتحذيرات أمان فريق تطوير Solidity، هناك ثغرات أمنية في عدة إصدارات من مترجم Solidity. وظيفة مترجم Solidity هي تحويل كود العقد الذكي إلى كود تعليمات (EVM) الخاص بـ Ethereum Virtual Machine، والتي سيتم رفعها في النهاية إلى Ethereum وتنفيذها بواسطة EVM.

من الضروري التمييز بين ثغرات مترجم Solidity وثغرات EVM نفسها. ثغرات EVM تشير إلى المشاكل الأمنية التي قد تحدث أثناء تنفيذ تعليمات الآلة الافتراضية، والتي قد تؤثر على شبكة Ethereum بأكملها. بينما ثغرات مترجم Solidity تشير إلى المشاكل التي تحدث أثناء تحويل Solidity إلى كود EVM، والتي لن تؤثر مباشرة على شبكة Ethereum، لكنها قد تؤدي إلى اختلاف كود EVM الناتج عن توقعات المطور.

من المخاطر الناتجة عن ثغرات مترجم Solidity أنها قد تؤدي إلى عدم تطابق كود EVM الناتج مع توقعات مطوري العقود الذكية. نظرًا لأن العقود الذكية تتعلق عادةً بأصول العملات المشفرة للمستخدمين، فإن أي خطأ ناتج عن المترجم قد يؤدي إلى خسارة أصول المستخدمين، مما ينتج عنه عواقب وخيمة.

ينصب تركيز المطورين والمراجعين غالبًا على منطق العقد والمشكلات الأمنية الشائعة، بينما يصعب اكتشاف ثغرات المترجم من خلال تدقيق الكود. يحتاج الأمر إلى تحليل مشترك يجمع بين إصدار المترجم المحدد وأنماط الكود لتحديد ما إذا كانت العقود الذكية تتأثر بثغرات المترجم.

إليك بعض الأمثلة الحقيقية على ثغرات مجمع Solidity:

1. SOL-2016-9 تخزين البيانات عالي النظام

توجد هذه الثغرة في إصدارات أقدم من مترجم Solidity (>=0.1.6 <0.4.4). اعتبر الكود التالي:

صَلَابة العقد C { uint32 أ = 0x12345678; uint32 ب = 0 ؛ وظيفة f() عامة { a = a + 1; } ترجع الدالة run() العرض العام (uint32) { عودة ب ؛ } }

نظريًا، لم يتم تعديل المتغير b، يجب أن ترجع الدالة run() القيمة 0. لكن في الكود الناتج عن المترجم في نسخة الثغرات، ستعيد run() القيمة 1. وذلك لأن EVM تستخدم عناصر مكدس بحجم 32 بايت، بينما Solidity تدعم أنواع البيانات الأصغر مثل uint32. يحتاج المترجم عند المعالجة إلى مسح البتات العليا (clean up)، لكنه لم يعالج بشكل صحيح عند تجاوز السعة في الجمع، مما أدى إلى كتابة البت العلوي 1 في المتغير b.

2. SOL-2022-4 آثار جانب الذاكرة في التجميع المدمج

توجد هذه الثغرة في المترجم من الإصدار 0.8.13 إلى 0.8.15. اعتبر الكود التالي:

صلابة عقد C { وظيفة f() العوائد العامة النقية (uint) { التجميع { mstore(0 ، 0x42) } uint x; التجميع { x := mload(0) } أعد x; } }

يقوم المترجم بإزالة عمليات كتابة الذاكرة التي تبدو غير مفيدة من أجل التحسين، ولكنه أزال عن طريق الخطأ الوصول إلى الذاكرة عبر كتل assembly. وهذا أدى إلى أن الدالة f() تُرجع 0 بدلاً من 0x42 الصحيحة.

3. SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

تؤثر هذه الثغرة على المترجمات من الإصدار 0.5.8 إلى 0.8.16. اعتبر الشيفرة التالية:

صلابة العقد C { دالة f(string[1] calldata a) خارجية نقية تعيد (string memory) { إرجاع abi.decode019283746574839201abi.encode(a( ، )string([1])). } }

في الظروف العادية، يجب أن تعيد هذه الدالة السلسلة المدخلة. ولكن في إصدار الثغرات، ستعيد سلسلة فارغة. وذلك لأن المترجم قام بشكل خاطئ بتنظيف بعض البيانات أثناء ترميز مصفوفة calldata باستخدام abi، مما أدى إلى عدم توافق البيانات بعد الترميز والفك.

![تحليل ثغرات مترجم Solidity وإجراءات المواجهة][0]https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

فيما يتعلق بثغرات مترجم Solidity، قدم فريق أمان بلوكتشين Cobo الاقتراحات التالية:

إلى المطورين:

1. استخدام إصدار أحدث من مترجم Solidity، عادة ما تكون المشكلات الأمنية المعروفة أقل.

2. تحسين حالات الاختبار الوحدوية. معظم الأخطاء على مستوى المترجم تؤدي إلى عدم تطابق نتائج تنفيذ الشيفرة مع التوقعات، من خلال زيادة تغطية الاختبار يمكن تجنب هذه المشكلات.

3. تجنب استخدام التجميع الداخلي، والترميز/فك الترميز المعقد لـ abi، وما إلى ذلك، ولا تستخدم الميزات الجديدة والوظائف التجريبية بشكل أعمى. ترتبط معظم ثغرات المترجمين بهذه العمليات المعقدة.

إلى موظفي الأمن:

1. لا تتجاهل المخاطر الأمنية التي قد يقدمها المترجم أثناء التدقيق. النقطة ذات الصلة هي SWC-102: إصدار المترجم القديم.

2. خلال عملية التطوير، يجب حث فريق التطوير على ترقية إصدار المترجم، ويمكن إدخال فحص الإصدار التلقائي في CI/CD.

3. لا داعي للقلق المفرط بشأن ثغرات المترجم. معظم الثغرات تظهر فقط في أنماط معينة من الشفرة، ويجب تقييم التأثيرات الأمنية بناءً على المشروع المحدد.

بعض الموارد المفيدة:

• تنبيه أمان رسمي من Solidity:
• قائمة الأخطاء الرسمية لـ Solidity:
• قائمة أخطاء المجمعات في الإصدارات المختلفة:
• علامة التحذير في الزاوية اليمنى العليا من صفحة عقد Etherscan يمكن أن تشير إلى الثغرات الأمنية الموجودة في إصدار المترجم الحالي

![تحليل ثغرات مترجم Solidity والتدابير المتخذة])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(

بشكل عام، يجب على المطورين وموظفي الأمان أن يوليوا اهتمامًا للمخاطر الأمنية المحتملة الناجمة عن ثغرات مجمع Solidity، واتخاذ التدابير المناسبة لتقليل هذه المخاطر وضمان أمان العقود الذكية.