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

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

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

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

ثغرة في مترجم Solidity

الوظيفة الرئيسية لمجمع Solidity هي تحويل كود العقد الذكي إلى كود تعليمات (EVM) الخاص بالآلة الافتراضية للإيثيريوم. يتم تحميل هذه التعليمات إلى الإيثيريوم من خلال حزم المعاملات، وفي النهاية يتم تحليلها وتنفيذها بواسطة EVM.

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

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

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

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

مثال على ثغرات مترجم Solidity

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

SOL-2016-9 تخزين نظيف للبايت عالي الطلب

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

اعتبر الشيفرة التالية:

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

لم يتم تعديل المتغير b في التخزين، لذا يجب أن تعيد دالة run() القيمة الافتراضية 0. ولكن في التعليمات البرمجية التي تم إنشاؤها بواسطة المترجم في إصدار الثغرة، ستعيد run() القيمة 1.

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

سبب حدوث هذه الظاهرة هو أن EVM يستخدم آلة افتراضية قائمة على المكدس، حيث يكون كل عنصر في المكدس بحجم 32 بايت ( أي بحجم متغير uint256 ). من ناحية أخرى، فإن كل فتحة في التخزين الأساسي storage هي أيضًا بحجم 32 بايت. تدعم لغة Solidity أنواع البيانات التي تقل عن 32 بايت مثل uint32، وعند معالجة هذه الأنواع، يحتاج المترجم إلى إجراء عمليات تنظيف مناسبة على الأجزاء العليا منها (clean up) لضمان صحة البيانات. في الحالة المذكورة، عندما ينتج عن عملية الجمع تجاوز سعة الأعداد، لم يقم المترجم بتنظيف الأجزاء العليا من النتيجة بشكل صحيح، مما أدى إلى كتابة بت واحد في الأجزاء العليا في التخزين، مما أدى في النهاية إلى覆盖 المتغير a بالمتغير b، مما غير قيمة المتغير b إلى 1.

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

توجد هذه الثغرة في المترجمين من الإصدار >=0.8.13 <0.8.15.

اعتبر الكود التالي:

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

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

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

لا توجد مشكلة في هذه الاستراتيجية التحسينية نفسها، ولكن في التنفيذ المحدد لمترجم Solidity، يتم تطبيق هذا النوع من التحسين فقط على كتلة assembly الوحيدة. في الكود PoC المذكور، يوجد الكتابة والوصول إلى الذاكرة 0 في كتلتي assembly مختلفتين، بينما قام المترجم فقط بتحليل وتحسين كتلة assembly المنفصلة. نظرًا لعدم وجود أي عملية قراءة بعد الكتابة إلى الذاكرة 0 في كتلة assembly الأولى، يتم اعتبار هذه التعليمات الكتابية زائدة، وسيتم إزالتها، مما يؤدي إلى حدوث خطأ. في الإصدار المتأثر، ستعيد الدالة f() القيمة 0، بينما يجب أن تكون القيمة الصحيحة 0x42.

SOL-2022-6 رأس إعادة ترميز ABI تجاوز سعة المصفوفة الثابتة مع تنظيف

تؤثر هذه الثغرة على المترجمين من الإصدار 0.5.8 إلى أقل من 0.8.16.

ضع في اعتبارك الكود التالي:

صلابة عقد C { وظيفة f(string[1] بيانات المكالمات a) العوائد العامة النقية (string memory) { إرجاع abi.decode019283746574839201abi.encode(a( ، )string([1])). } }

في الظروف العادية، يجب أن تكون قيمة المتغير a التي تعيدها الشيفرة أعلاه هي "aaaa". ولكن في نسخة الثغرة، ستعيد سلسلة فارغة "".

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

من الجدير بالذكر أن Solidity عند إجراء استدعاء خارجي وemit event، يقوم بشكل ضمني بترميز المعلمات باستخدام abi.encode، لذلك فإن احتمال ظهور كود الثغرات المذكورة أعلاه سيكون أعلى مما قد يتوقعه المرء.

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

نصائح الأمان

بالنسبة لتهديدات ثغرات مُجمّع Solidity، نقدم الاقتراحات التالية للمطورين وفرق الأمان:

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

• استخدم إصدارًا أحدث من مُجمّع Solidity. على الرغم من أن الإصدارات الجديدة قد تُدخل مشكلات أمان جديدة، إلا أن المشكلات المعروفة عادة ما تكون أقل في الإصدارات القديمة.

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

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

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

• عند إجراء تدقيق أمني لكود Solidity، لا تتجاهل المخاطر الأمنية التي قد يقدمها المترجم. العنصر المقابل في تصنيف ضعف العقود الذكية ) SWC( هو SWC-102: إصدار المترجم عفا عليه الزمن.

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

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

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

• منشورات التنبيهات الأمنية التي تصدرها فريق Solidity بشكل دوري
• قائمة الأخطاء التي يتم تحديثها بانتظام من المستودع الرسمي لـ Solidity
• قائمة أخطاء المترجمين لكل إصدار. يمكن إدخال فحص تلقائي لإصدار المترجم أثناء عملية CI/CD، لإعلام المستخدم بالثغرات الأمنية الموجودة في الإصدار الحالي.
• على Etherscan عقد - يمكن أن يشير رمز علامة التعجب مثلث في الزاوية اليمنى العليا من صفحة الكود إلى الثغرات الأمنية الموجودة في إصدار المترجم الحالي.

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

ملخص

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