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

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

Наприклад, коли браузер компілює та виконує код JavaScript, це може призвести до віддаленого виконання коду через вразливість парсера, що дає змогу зловмисникам отримати контроль над браузером жертви або навіть над операційною системою. Дослідження також показують, що помилки компілятора C++ можуть призвести до віддаленого виконання коду та інших серйозних наслідків.

Компилятор Solidity також має вразливості безпеки. Згідно з попередженнями безпеки розробницької команди, у кількох версіях компілятора Solidity виявлено проблеми з безпекою.

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

Оскільки смарт-контракти зазвичай пов'язані з криптовалютними активами користувачів, будь-які помилки, спричинені компілятором, можуть мати серйозні наслідки. Лише перевірка вихідного коду контракту не дозволяє легко виявити вразливості компілятора; необхідно проводити аналіз у поєднанні з конкретними версіями та кодовими шаблонами.

Нижче через кілька реальних прикладів, показано конкретні форми, причини та наслідки вразливостей компілятора Solidity.

SOL-2016-9 HighOrderByteCleanStorage

Ця вразливість існує в ранніх версіях компілятора Solidity (>=0.1.6 <0.4.4).

Розгляньте наступний код:

солідність контракт C { uint32 a = 0x1234; uint32 b = 0; функція f() публічна { a += 1; } функція run() публічний перегляд повертає (uint) { повернути b; } }

Змінна b не була змінена, функція run() повинна повертати значення за замовчуванням 0. Але у скомпільованому коді версії компілятора з вразливістю, run() поверне 1.

Це тому, що EVM використовує стекові елементи розміром 32 байти, тоді як Solidity підтримує типи, такі як uint32, які менші за 32 байти. Компілятору потрібно виконати операцію очищення старших бітів, щоб забезпечити коректність даних. Під час переповнення при додаванні компілятор не очистив старші біти належним чином, внаслідок чого переповнений 1 біт був записаний у сховище, перекривши змінну b.

SOL-2022-4 InlineAssemblyMemorySideEffects

Ця вразливість існує в компіляторах версій >=0.8.13 <0.8.15.

Розгляньте наступний код:

солідність контракт C { функція f() публічна чиста повертає (uint) { збірка { mstore(0, 0x42) } uint x; збірка { x := mload(0) } повернути x; } }

Компілятор під час оптимізації аналізує контрольний потік та потік даних, щоб зменшити обсяг коду та оптимізувати споживання газу. Але така оптимізація може легко призвести до помилок.

У цьому прикладі компілятор помилково вважає, що запис у пам'ять 0 в першому блоці асемблера є зайвим, видаляє його, в результаті чого функція f() повертає 0 замість правильного 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Ця уразливість впливає на компілятори версій >= 0.5.8 < 0.8.16.

Розгляньте наступний код:

солідність контракт C { функція f(string[1] calldata a) public pure повертає (string memory) { повернути abi.decode(abi.encode(a), (стрічка[1]))[0]; } }

У нормальних умовах цей код має повернути значення змінної a "aaaa". Але в уразливій версії він поверне порожній рядок "".

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

Важливо зазначити, що при зовнішньому виклику та генеруванні події відбувається неявне виконання abi.encode, тому ймовірність виникнення такого вразливості є досить високою.

Рекомендації щодо безпеки

Для розробників:

• Використання новішої версії компілятора Solidity, як правило, містить менше відомих проблем безпеки.
• Удосконалити модульні тести, підвищити покриття коду, що допоможе виявити проблеми, викликані компілятором.
• Уникайте використання вбудованого асемблера, складного ABI кодування та декодування тощо, не використовуйте нові функції та експериментальні можливості без роздумів.

Для безпеки персоналу:

• Не ігноруйте ризики, які можуть бути введені компілятором під час аудиту, відповідно до пункту перевірки SWC-102.
• У процесі SDL, просувати оновлення версії компілятора, розглянути можливість впровадження автоматичної перевірки.
• Оцінка фактичного впливу вразливостей компілятора, не варто занадто панікувати.

Деякі корисні ресурси:

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

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