Аналіз вразливостей компілятора Solidity та стратегії реагування

Компілятор є одним з основних компонентів сучасних комп'ютерних систем, його основна функція полягає в перетворенні вихідного коду мов програмування високого рівня на інструкційний код, який може виконувати комп'ютер. У порівнянні з безпекою прикладного коду, проблеми безпеки самого компілятора часто можуть бути проігноровані. Проте у певних ситуаціях вразливості компілятора також можуть призвести до серйозних ризиків безпеки.

Роль компілятора Solidity полягає в перетворенні коду смарт-контрактів на інструкційний код віртуальної машини Ethereum (EVM). На відміну від вразливостей самої EVM, вразливості компілятора Solidity не впливають безпосередньо на мережу Ethereum, але можуть призвести до того, що згенерований код EVM не відповідатиме очікуванням розробника, що може вплинути на нормальну роботу смарт-контракту, потенційно призводячи до втрати активів користувачів.

Ось кілька реальних прикладів вразливостей компілятора Solidity:

1. SOL-2016-9 HighOrderByteCleanStorage

Вразливість існує в ранніх версіях компілятора Solidity (>=0.1.6 <0.4.4). Оскільки компілятор не очищав старші біти належним чином при обробці переповнення цілого числа, це могло призвести до випадкової зміни значень сусідніх змінних.

2. SOL-2022-4 Впливи на пам'ять InlineAssembly

Ця вразливість існує в компіляторах версій від 0.8.13 до 0.8.15. Через проблеми з оптимізаційною стратегією компілятора, можливо, буде помилково видалено команди запису в пам'ять в інлайн-асемблері, що призведе до неналежної роботи програми.

3. SOL-2022-6 AbiПерекодуванняГоловиПереповненняЗСтатичнимМасивомОчистка

Ця вразливість впливає на версії компілятора від 0.5.8 до 0.8.16. Під час виконання операції abi.encode з масивом типу calldata може помилково змінюватися сусідні дані, що призводить до несумісності закодованих і декодованих даних.

Щодо вразливостей компілятора Solidity, рекомендується розробникам:

• Використовуйте новішу версію компілятора Solidity
• Поліпшити тестові випадки для модулів, підвищити покриття коду
• Намагайтеся уникати використання складних мовних особливостей, таких як вбудовані асемблери, багатовимірні масиви та кодування/декодування ABI тощо.

Для фахівців з безпеки рекомендується:

• Під час аудиту слід враховувати потенційні ризики безпеки, які можуть бути внесені компілятором
• У процесі SDL закликати команду розробників оновити версію компілятора
• Впровадження автоматичної перевірки версії компілятора в CI/CD

Слід зазначити, що більшість вразливостей компіляторів активуються лише у певних кодових шаблонах, тому використання вразливої версії компілятора не означає, що контракт обов'язково має ризики безпеки; фактичний вплив потрібно оцінювати конкретно.

Щоб продовжувати стежити за проблемами безпеки компілятора Solidity, можна звернутися до наступних ресурсів:

• Попередження про безпеку, опубліковане командою Solidity
• Список помилок у офіційному репозиторії Solidity
• Список помилок компіляторів різних версій
• Повідомлення про безпеку на сторінці коду контракту на Etherscan

Зосередившись на безпеці компілятора, раціонально використовуючи особливості мови та зберігаючи пильність, розробники та спеціалісти з безпеки можуть краще забезпечити безпеку смарт-контрактів.