المترجم هو أحد المكونات الأساسية في أنظمة الكمبيوتر الحديثة. إنه يقوم بتحويل لغات البرمجة عالية المستوى السهلة الفهم للبشر إلى تعليمات منخفضة المستوى يمكن للكمبيوتر تنفيذها. على الرغم من أن المطورين وخبراء الأمن يركزون عادةً على أمان كود التطبيق، فإن مشكلات الأمان المتعلقة بالمترجم نفسه لا ينبغي التغاضي عنها. يمكن أن تؤدي ثغرات المترجم في بعض الحالات إلى مخاطر أمنية خطيرة.
على سبيل المثال، عند解析 وتنفيذ كود JavaScript في المتصفح، قد تؤدي ثغرات محرك JavaScript إلى تعرض المستخدمين لهجمات تنفيذ التعليمات البرمجية عن بُعد عند زيارة صفحات ويب ضارة، مما يسمح للمهاجم بالتحكم في متصفح الضحية أو حتى نظام التشغيل. بالإضافة إلى ذلك، قد تؤدي الأخطاء في مترجم C++ إلى عواقب وخيمة مثل تنفيذ التعليمات البرمجية عن بُعد.
لا يُستثنى مُجمع Solidity من ذلك، حيث توجد ثغرات أمنية في الإصدارات المتعددة. وظيفة مُجمع Solidity هي تحويل كود العقود الذكية إلى تعليمات Ethereum Virtual Machine (EVM)، والتي تُنفذ في النهاية في EVM. من المهم ملاحظة أن ثغرات مُجمع Solidity تختلف عن ثغرات EVM نفسها. تشير ثغرات EVM إلى مشكلات الأمان عند تنفيذ التعليمات بواسطة الآلة الافتراضية، مما قد يؤثر على شبكة Ethereum بأكملها. بينما ثغرات مُجمع Solidity هي مشاكل تظهر عند تحويل Solidity إلى كود EVM.
من الأضرار المحتملة لثغرات مترجم Solidity هي أن الشيفرة البرمجية الناتجة عن EVM قد لا تتوافق مع ما يتوقعه المطور. نظرًا لأن العقود الذكية تتعلق عادةً بأصول العملات المشفرة للمستخدمين، فإن أي خطأ ناتج عن المترجم قد يؤدي إلى خسارة أصول المستخدمين، مما ينجم عنه عواقب وخيمة. غالبًا ما يركز المطورون والمراجعين على تنفيذ منطق العقد والثغرات الشائعة، بينما تتطلب ثغرات المترجم تحليلًا يتضمن إصدارات معينة وأنماط الشيفرة.
سوف تستعرض الفقرات التالية عدة حالات حقيقية لتوضيح الأشكال المحددة، والأسباب، والأضرار الناتجة عن ثغرات مترجم Solidity.
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.
من الصعب اكتشاف هذا التباين من خلال مراجعة الكود البسيطة. على الرغم من أن تأثير الكود النموذجي محدود، إلا أنه إذا تم استخدام متغير b في التحقق من الأذونات أو محاسبة الأصول، ستكون العواقب وخيمة.
سبب هذه المشكلة هو أن EVM يستخدم عناصر مكدس بحجم 32 بايت، بينما كل فتحة في التخزين الأساسي هي أيضًا 32 بايت. تدعم Solidity أنواع البيانات الأصغر من 32 بايت مثل uint32، ويحتاج المترجم إلى تنظيف البيانات العليا (clean up) عند التعامل مع هذه الأنواع لضمان صحة البيانات. في هذه الحالة، لم ينظف المترجم النتيجة العالية بشكل صحيح بعد تجاوز عملية الجمع، مما أدى إلى كتابة بتة التجاوز 1 في التخزين، مما غطى المتغير b.
SOL-2022-4 تأثيرات الذاكرة الجانبية للتجميع المضمن
هذه الثغرة موجودة في المترجم من الإصدار 0.8.13 إلى 0.8.15. اعتبر الكود التالي:
صلابة
عقد C {
وظيفة f() العوائد العامة النقية (uint) {
التجميع {
mstore(0 ، 0x42)
}
uint x;
التجميع {
x := mload(0)
}
عُد إلى x;
}
}
يعمل مترجم Solidity على إجراء تحليل عميق لتدفق التحكم والبيانات أثناء عملية التحسين، لتقليل حجم الكود الناتج وتحسين استهلاك الغاز. على الرغم من أن هذا النوع من التحسينات شائع، إلا أن الوضع معقد، مما قد يؤدي إلى ظهور أخطاء أو ثغرات أمنية.
تأتي مشكلة الشيفرة المذكورة من هذا النوع من التحسينات. يعتبر المترجم أنه إذا عدل دالة ما البيانات الموجودة في موضع الذاكرة 0، ولكن لم يتم استخدام تلك البيانات لاحقًا، فيمكنه إزالة تعليمات التعديل لتوفير الغاز. لكن هذا النوع من التحسين ينطبق فقط داخل كتلة التجميع الواحدة.
في هذا المثال، تتم الكتابة والوصول إلى الذاكرة 0 في كتلتين assembly مختلفتين. قام المترجم بتحليل الكتل 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 يقوم بشكل ضمني بترميز المعاملات باستخدام abi.encode عند إجراء استدعاءات خارجية وإصدار الأحداث، لذا قد تكون تأثيرات هذه الثغرة أكبر مما كان متوقعًا.
نصائح الأمان
استنادًا إلى تحليل ثغرات مترجم Solidity، نقدم الاقتراحات التالية للمطورين والجهات الأمنية:
إلى المطورين:
استخدم إصدارًا أحدث من مترجم Solidity. على الرغم من أن الإصدارات الجديدة قد تقدم مشاكل جديدة، إلا أن المشاكل الأمنية المعروفة عادة ما تكون أقل.
تحسين اختبارات الوحدة. معظم الأخطاء على مستوى المترجم تؤدي إلى نتائج تنفيذ لا تتوافق مع التوقعات، وهذه المشاكل نادراً ما يمكن اكتشافها من خلال مراجعة الكود، ولكن من السهل الكشف عنها أثناء الاختبار. يمكن أن يساعد رفع مستوى تغطية الكود في تجنب هذه المشاكل إلى أقصى حد.
تجنب استخدام التجميع الداخلي، وعمليات الترميز المتقدمة لـ abi، وما إلى ذلك، ولا تستخدم الميزات الجديدة والوظائف التجريبية بشكل أعمى. تتعلق معظم الثغرات التاريخية بهذه العمليات المعقدة.
إلى أفراد الأمن:
لا تتجاهل المخاطر الأمنية التي قد يقدمها المُجمّع أثناء التدقيق. البند المقابل في تصنيف نقاط ضعف العقود الذكية [0] SWC ( هو SWC-102: إصدار المُجمّع القديم.
في عملية تطوير SDL، يجب على الفريق المطور الضغط على ترقية إصدار المترجم، والنظر في إدخال فحص تلقائي لإصدار المترجم في CI/CD.
لا داعي للقلق المفرط بشأن ثغرات المترجم. معظم الثغرات تُtrigger فقط في أنماط كود محددة، واستخدام العقود المترجمة بإصدارات معرضة للثغرات لا يعني بالضرورة وجود خطر، ويجب تقييم ذلك بناءً على الظروف المحددة.
بعض الموارد المفيدة:
تنبيهات الأمان التي تصدرها فريق Solidity بانتظام
قائمة الأخطاء التي يتم تحديثها بانتظام من مستودع Solidity الرسمي
قائمة أخطاء المترجمين لكل إصدار، يمكن استخدامها للتحقق التلقائي في CI/CD
يمكن أن تشير علامة التحذير في الزاوية اليمنى العليا من صفحة كود العقد على Etherscan إلى الثغرات الأمنية الموجودة في إصدار المترجم الحالي.
![تحليل ثغرات مترجم Solidity وإجراءات التعامل معها])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
ملخص
تتناول هذه المقالة مفهوم ثغرات مترجم Solidity، وتحلل المخاطر الأمنية التي قد تؤدي إليها في تطوير Ethereum، كما تقدم نصائح أمان عملية للمطورين والمهنيين في مجال الأمن. على الرغم من أن ثغرات المترجم ليست شائعة، إلا أن لها تأثيرات بعيدة المدى، مما يستدعي اهتمام فرق التطوير والأمان.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحليل ثغرات مترجم سوليديتي: التأثيرات، الحالات واستراتيجيات المواجهة
تحليل ثغرات مترجم Solidity واستراتيجيات المواجهة
المترجم هو أحد المكونات الأساسية في أنظمة الكمبيوتر الحديثة. إنه يقوم بتحويل لغات البرمجة عالية المستوى السهلة الفهم للبشر إلى تعليمات منخفضة المستوى يمكن للكمبيوتر تنفيذها. على الرغم من أن المطورين وخبراء الأمن يركزون عادةً على أمان كود التطبيق، فإن مشكلات الأمان المتعلقة بالمترجم نفسه لا ينبغي التغاضي عنها. يمكن أن تؤدي ثغرات المترجم في بعض الحالات إلى مخاطر أمنية خطيرة.
على سبيل المثال، عند解析 وتنفيذ كود JavaScript في المتصفح، قد تؤدي ثغرات محرك JavaScript إلى تعرض المستخدمين لهجمات تنفيذ التعليمات البرمجية عن بُعد عند زيارة صفحات ويب ضارة، مما يسمح للمهاجم بالتحكم في متصفح الضحية أو حتى نظام التشغيل. بالإضافة إلى ذلك، قد تؤدي الأخطاء في مترجم C++ إلى عواقب وخيمة مثل تنفيذ التعليمات البرمجية عن بُعد.
لا يُستثنى مُجمع Solidity من ذلك، حيث توجد ثغرات أمنية في الإصدارات المتعددة. وظيفة مُجمع Solidity هي تحويل كود العقود الذكية إلى تعليمات Ethereum Virtual Machine (EVM)، والتي تُنفذ في النهاية في EVM. من المهم ملاحظة أن ثغرات مُجمع Solidity تختلف عن ثغرات EVM نفسها. تشير ثغرات EVM إلى مشكلات الأمان عند تنفيذ التعليمات بواسطة الآلة الافتراضية، مما قد يؤثر على شبكة Ethereum بأكملها. بينما ثغرات مُجمع Solidity هي مشاكل تظهر عند تحويل Solidity إلى كود EVM.
من الأضرار المحتملة لثغرات مترجم Solidity هي أن الشيفرة البرمجية الناتجة عن EVM قد لا تتوافق مع ما يتوقعه المطور. نظرًا لأن العقود الذكية تتعلق عادةً بأصول العملات المشفرة للمستخدمين، فإن أي خطأ ناتج عن المترجم قد يؤدي إلى خسارة أصول المستخدمين، مما ينجم عنه عواقب وخيمة. غالبًا ما يركز المطورون والمراجعين على تنفيذ منطق العقد والثغرات الشائعة، بينما تتطلب ثغرات المترجم تحليلًا يتضمن إصدارات معينة وأنماط الشيفرة.
سوف تستعرض الفقرات التالية عدة حالات حقيقية لتوضيح الأشكال المحددة، والأسباب، والأضرار الناتجة عن ثغرات مترجم Solidity.
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.
من الصعب اكتشاف هذا التباين من خلال مراجعة الكود البسيطة. على الرغم من أن تأثير الكود النموذجي محدود، إلا أنه إذا تم استخدام متغير b في التحقق من الأذونات أو محاسبة الأصول، ستكون العواقب وخيمة.
سبب هذه المشكلة هو أن EVM يستخدم عناصر مكدس بحجم 32 بايت، بينما كل فتحة في التخزين الأساسي هي أيضًا 32 بايت. تدعم Solidity أنواع البيانات الأصغر من 32 بايت مثل uint32، ويحتاج المترجم إلى تنظيف البيانات العليا (clean up) عند التعامل مع هذه الأنواع لضمان صحة البيانات. في هذه الحالة، لم ينظف المترجم النتيجة العالية بشكل صحيح بعد تجاوز عملية الجمع، مما أدى إلى كتابة بتة التجاوز 1 في التخزين، مما غطى المتغير b.
SOL-2022-4 تأثيرات الذاكرة الجانبية للتجميع المضمن
هذه الثغرة موجودة في المترجم من الإصدار 0.8.13 إلى 0.8.15. اعتبر الكود التالي:
صلابة عقد C { وظيفة f() العوائد العامة النقية (uint) { التجميع { mstore(0 ، 0x42) } uint x; التجميع { x := mload(0) } عُد إلى x; } }
يعمل مترجم Solidity على إجراء تحليل عميق لتدفق التحكم والبيانات أثناء عملية التحسين، لتقليل حجم الكود الناتج وتحسين استهلاك الغاز. على الرغم من أن هذا النوع من التحسينات شائع، إلا أن الوضع معقد، مما قد يؤدي إلى ظهور أخطاء أو ثغرات أمنية.
تأتي مشكلة الشيفرة المذكورة من هذا النوع من التحسينات. يعتبر المترجم أنه إذا عدل دالة ما البيانات الموجودة في موضع الذاكرة 0، ولكن لم يتم استخدام تلك البيانات لاحقًا، فيمكنه إزالة تعليمات التعديل لتوفير الغاز. لكن هذا النوع من التحسين ينطبق فقط داخل كتلة التجميع الواحدة.
في هذا المثال، تتم الكتابة والوصول إلى الذاكرة 0 في كتلتين assembly مختلفتين. قام المترجم بتحليل الكتل 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 يقوم بشكل ضمني بترميز المعاملات باستخدام abi.encode عند إجراء استدعاءات خارجية وإصدار الأحداث، لذا قد تكون تأثيرات هذه الثغرة أكبر مما كان متوقعًا.
نصائح الأمان
استنادًا إلى تحليل ثغرات مترجم Solidity، نقدم الاقتراحات التالية للمطورين والجهات الأمنية:
إلى المطورين:
إلى أفراد الأمن:
بعض الموارد المفيدة:
![تحليل ثغرات مترجم Solidity وإجراءات التعامل معها])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
ملخص
تتناول هذه المقالة مفهوم ثغرات مترجم Solidity، وتحلل المخاطر الأمنية التي قد تؤدي إليها في تطوير Ethereum، كما تقدم نصائح أمان عملية للمطورين والمهنيين في مجال الأمن. على الرغم من أن ثغرات المترجم ليست شائعة، إلا أن لها تأثيرات بعيدة المدى، مما يستدعي اهتمام فرق التطوير والأمان.