Аналіз вразливостей компілятора Solidity та стратегії реагування
Компілятор є однією з основних складових сучасних комп'ютерних систем. Це програма, яка перетворює мову програмування високого рівня на інструкції, що можуть виконуватися комп'ютером. Хоча розробники та експерти з безпеки зазвичай зосереджуються на безпеці коду програм, безпека самого компілятора також є важливою.
Компілятори, як комп'ютерні програми, також можуть мати вразливості безпеки, які в певних випадках можуть призвести до серйозних ризиків безпеки. Наприклад, під час розбору та виконання JavaScript-коду браузер може піддаватися атакам через вразливості JavaScript-движка, що може призвести до того, що зловмисники отримають контроль над браузером жертви або навіть її операційною системою.
Компіллятор Solidity не є винятком. Згідно з попередженнями команди розробників Solidity про безпеку, у кількох версіях компіллятора Solidity є вразливості.
Вразливість компілятора Solidity
Роль компілятора Solidity полягає в перетворенні коду смарт-контракту на інструкції коду віртуальної машини Ethereum (EVM). Ці інструкції EVM упаковуються в транзакції та завантажуються в Ethereum, зрештою виконуються EVM.
Потрібно розрізняти вразливості компілятора Solidity та вразливості самого EVM. Вразливості EVM - це вразливості безпеки, які виникають під час виконання інструкцій віртуальної машини, що може вплинути на всю мережу Ethereum. Вразливості компілятора Solidity - це проблеми, що виникають під час перетворення Solidity у код EVM.
Вразливості компілятора Solidity не впливають безпосередньо на мережу Ethereum, але можуть призвести до того, що згенерований код EVM не відповідатиме очікуванням розробника. Оскільки смарт-контракти зазвичай пов'язані з криптовалютними активами, будь-яка помилка, викликана компілятором, може призвести до втрати активів користувачів, що матиме серйозні наслідки.
Лише через аудит вихідного коду контракту важко виявити вразливості компілятора. Потрібно поєднати специфічну версію компілятора та шаблон коду для аналізу, щоб визначити, чи підлягає контракт впливу вразливостей компілятора.
Приклад вразливості компілятора Solidity
Ось кілька реальних прикладів вразливостей компілятора Solidity, які демонструють конкретні форми, причини та загрози.
SOL-2016-9 HighOrderByteCleanStorage
Ця вразливість існує в ранніх версіях компілятора Solidity (>=0.1.6 <0.4.4).
Розгляньте наступний код:
солідність
контракт C {
uint32 a = 0x12345678;
uint32 b = 0;
функція run() повертає (uint256) {
a = a + 1;
повернути b;
}
}
змінна storage b не була змінена, функція run() повинна повертати значення за замовчуванням 0. Але в уразливих версіях компілятора run() поверне 1.
Ця ситуація, яка не відповідає очікуванням, може призвести до серйозних наслідків, якщо змінна b використовується для перевірки прав доступу або обліку активів.
Причиною цього явища є те, що EVM використовує стекові елементи та слоти пам'яті розміром 32 байти, тоді як Solidity підтримує менші типи даних, такі як uint32. Компілятор під час обробки цих типів повинен очищати старші біти, але в разі переповнення цілого числа це не було правильно оброблено, внаслідок чого старший біт 1 був записаний у storage, перекривши змінну b.
SOL-2022-4 InlineAssemblyMemoryПобічні ефекти
Ця вразливість існує в компіляторах версій >=0.8.13 <0.8.15.
Розгляньте наступний код:
солідність
контракт C {
функція f() публічна чиста повертає (uint) {
збірка {
mstore(0, 0x42)
}
uint x;
збірка {
x := mload(0)
}
повернути x;
}
}
Ця уразливість виникає через оптимізацію компілятора. Компілятор намагається видалити, здавалося б, надмірні операції запису в пам'ять, але неправильно аналізує блоки асемблера. У вразливій версії функція f() поверне 0, а не правильне 0x42.
Ця вразливість впливає на компілятори версій >= 0.5.8 < 0.8.16.
Розгляньте наступний код:
солідність
контракт C {
функція f(string[1] calldata a) зовнішня чиста повертає (string пам'яті) {
повернути abi.decode(abi.encode(a), (стрічка[1]))[0];
}
}
У нормальних умовах, цей код має повернути значення змінної a "aaaa". Але в уразливій версії він поверне порожній рядок "".
Це сталося через те, що Solidity неправильно очистив певні дані під час виконання операції abi.encode з масивами типу calldata, що призвело до зміни сусідніх даних і викликало несумісність даних після кодування та декодування.
Варто зазначити, що Solidity під час виконання зовнішніх викликів та емісії подій імпліцитно виконує abi.encode, тому вплив таких вразливостей може бути ширшим, ніж очікувалося.
Рекомендації з безпеки
На основі аналізу моделі загроз вразливостей компілятора Solidity та історичного огляду вразливостей, пропонуємо наступні рекомендації для розробників та фахівців з безпеки:
Для розробників:
Використовуйте новішу версію компілятора Solidity. Нові версії зазвичай виправляють відомі проблеми безпеки.
Поліпшення юніт-тестування. Більшість помилок на рівні компілятора призводять до того, що результати виконання коду не відповідають очікуванням; підвищення покриття коду може виявити такі проблеми на етапі тестування.
Уникайте використання вбудованого асемблера, складного ABI кодування та декодування та інших операцій. Більшість історичних вразливостей пов'язані з цими складними особливостями.
для безпеки.
Не ігноруйте потенційні ризики безпеки, які можуть бути введені компілятором під час аудиту. Відповідна перевірка для Smart Contract Weakness Classification(SWC) є SWC-102.
У внутрішньому процесі SDL, спонукати команду розробників оновити версію компілятора Solidity, розглянути можливість впровадження автоматичної перевірки в CI/CD.
Не варто надмірно турбуватися про вразливості компілятора. Більшість вразливостей активуються лише в конкретних кодових шаблонах, і їх фактичний вплив потрібно оцінювати залежно від конкретних обставин.
Практичні ресурси:
Безпекове повідомлення від команди Solidity:
Офіційний список помилок Solidity:
Список помилок компілятора для всіх версій:
Попереджувальний знак у правому верхньому куті сторінки коду контракту Etherscan може вказувати на вразливості безпеки, що існують в поточній версії компілятора.
Резюме
Ця стаття представляє концепцію вразливостей компілятора Solidity, аналізує потенційні ризики безпеки, які можуть виникнути під час реальної розробки на Ethereum, та надає практичні рекомендації для розробників і фахівців з безпеки. Зрозумівши характеристики та вплив вразливостей компілятора, можна краще забезпечити безпеку смарт-контрактів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
5
Поділіться
Прокоментувати
0/400
DataBartender
· 10год тому
Безпека не має кінця, тимчасові патчі не витримують.
Аналіз вразливостей компілятора Solidity та стратегії безпеки
Аналіз вразливостей компілятора Solidity та стратегії реагування
Компілятор є однією з основних складових сучасних комп'ютерних систем. Це програма, яка перетворює мову програмування високого рівня на інструкції, що можуть виконуватися комп'ютером. Хоча розробники та експерти з безпеки зазвичай зосереджуються на безпеці коду програм, безпека самого компілятора також є важливою.
Компілятори, як комп'ютерні програми, також можуть мати вразливості безпеки, які в певних випадках можуть призвести до серйозних ризиків безпеки. Наприклад, під час розбору та виконання JavaScript-коду браузер може піддаватися атакам через вразливості JavaScript-движка, що може призвести до того, що зловмисники отримають контроль над браузером жертви або навіть її операційною системою.
Компіллятор Solidity не є винятком. Згідно з попередженнями команди розробників Solidity про безпеку, у кількох версіях компіллятора Solidity є вразливості.
Вразливість компілятора Solidity
Роль компілятора Solidity полягає в перетворенні коду смарт-контракту на інструкції коду віртуальної машини Ethereum (EVM). Ці інструкції EVM упаковуються в транзакції та завантажуються в Ethereum, зрештою виконуються EVM.
Потрібно розрізняти вразливості компілятора Solidity та вразливості самого EVM. Вразливості EVM - це вразливості безпеки, які виникають під час виконання інструкцій віртуальної машини, що може вплинути на всю мережу Ethereum. Вразливості компілятора Solidity - це проблеми, що виникають під час перетворення Solidity у код EVM.
Вразливості компілятора Solidity не впливають безпосередньо на мережу Ethereum, але можуть призвести до того, що згенерований код EVM не відповідатиме очікуванням розробника. Оскільки смарт-контракти зазвичай пов'язані з криптовалютними активами, будь-яка помилка, викликана компілятором, може призвести до втрати активів користувачів, що матиме серйозні наслідки.
Лише через аудит вихідного коду контракту важко виявити вразливості компілятора. Потрібно поєднати специфічну версію компілятора та шаблон коду для аналізу, щоб визначити, чи підлягає контракт впливу вразливостей компілятора.
Приклад вразливості компілятора Solidity
Ось кілька реальних прикладів вразливостей компілятора Solidity, які демонструють конкретні форми, причини та загрози.
SOL-2016-9 HighOrderByteCleanStorage
Ця вразливість існує в ранніх версіях компілятора Solidity (>=0.1.6 <0.4.4).
Розгляньте наступний код:
солідність контракт C { uint32 a = 0x12345678; uint32 b = 0; функція run() повертає (uint256) { a = a + 1; повернути b; } }
змінна storage b не була змінена, функція run() повинна повертати значення за замовчуванням 0. Але в уразливих версіях компілятора run() поверне 1.
Ця ситуація, яка не відповідає очікуванням, може призвести до серйозних наслідків, якщо змінна b використовується для перевірки прав доступу або обліку активів.
Причиною цього явища є те, що EVM використовує стекові елементи та слоти пам'яті розміром 32 байти, тоді як Solidity підтримує менші типи даних, такі як uint32. Компілятор під час обробки цих типів повинен очищати старші біти, але в разі переповнення цілого числа це не було правильно оброблено, внаслідок чого старший біт 1 був записаний у storage, перекривши змінну b.
SOL-2022-4 InlineAssemblyMemoryПобічні ефекти
Ця вразливість існує в компіляторах версій >=0.8.13 <0.8.15.
Розгляньте наступний код:
солідність контракт C { функція f() публічна чиста повертає (uint) { збірка { mstore(0, 0x42) } uint x; збірка { x := mload(0) } повернути x; } }
Ця уразливість виникає через оптимізацію компілятора. Компілятор намагається видалити, здавалося б, надмірні операції запису в пам'ять, але неправильно аналізує блоки асемблера. У вразливій версії функція f() поверне 0, а не правильне 0x42.
SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Ця вразливість впливає на компілятори версій >= 0.5.8 < 0.8.16.
Розгляньте наступний код:
солідність контракт C { функція f(string[1] calldata a) зовнішня чиста повертає (string пам'яті) { повернути abi.decode(abi.encode(a), (стрічка[1]))[0]; } }
У нормальних умовах, цей код має повернути значення змінної a "aaaa". Але в уразливій версії він поверне порожній рядок "".
Це сталося через те, що Solidity неправильно очистив певні дані під час виконання операції abi.encode з масивами типу calldata, що призвело до зміни сусідніх даних і викликало несумісність даних після кодування та декодування.
Варто зазначити, що Solidity під час виконання зовнішніх викликів та емісії подій імпліцитно виконує abi.encode, тому вплив таких вразливостей може бути ширшим, ніж очікувалося.
Рекомендації з безпеки
На основі аналізу моделі загроз вразливостей компілятора Solidity та історичного огляду вразливостей, пропонуємо наступні рекомендації для розробників та фахівців з безпеки:
Для розробників:
Використовуйте новішу версію компілятора Solidity. Нові версії зазвичай виправляють відомі проблеми безпеки.
Поліпшення юніт-тестування. Більшість помилок на рівні компілятора призводять до того, що результати виконання коду не відповідають очікуванням; підвищення покриття коду може виявити такі проблеми на етапі тестування.
Уникайте використання вбудованого асемблера, складного ABI кодування та декодування та інших операцій. Більшість історичних вразливостей пов'язані з цими складними особливостями.
для безпеки.
Не ігноруйте потенційні ризики безпеки, які можуть бути введені компілятором під час аудиту. Відповідна перевірка для Smart Contract Weakness Classification(SWC) є SWC-102.
У внутрішньому процесі SDL, спонукати команду розробників оновити версію компілятора Solidity, розглянути можливість впровадження автоматичної перевірки в CI/CD.
Не варто надмірно турбуватися про вразливості компілятора. Більшість вразливостей активуються лише в конкретних кодових шаблонах, і їх фактичний вплив потрібно оцінювати залежно від конкретних обставин.
Практичні ресурси:
Резюме
Ця стаття представляє концепцію вразливостей компілятора Solidity, аналізує потенційні ризики безпеки, які можуть виникнути під час реальної розробки на Ethereum, та надає практичні рекомендації для розробників і фахівців з безпеки. Зрозумівши характеристики та вплив вразливостей компілятора, можна краще забезпечити безпеку смарт-контрактів.