Щоб посилити гарантії безпеки та зберігання для клієнтів, які торгують ERC-20 та іншими активами на основі смарт-контрактів, команда Coinbase Blockchain Security дослідила програмний рівень, який визначає поведінку цих активів: віртуальну машину Ethereum (EVM). Під час оцінки проектів, які змінюють EVM їхньої власної мережі, команда безпеки блокчейну Coinbase переглядає ключові зміни EVM, щоб визначити, чи може модифікована EVM забезпечити таку саму безпеку та гарантії зберігання, як оригінальна реалізація EVM.
Статус форка EVM
Станом на травень 2023 року віртуальна машина Ethereum (EVM) отримала титул «Великого брата» найпопулярнішої платформи для виконання смарт-контрактів. За даними DefiLlama, 9 із 10 найкращих мереж за Total Value Locked (TVL) підтримують смарт-контракти EVM. Тому глибоке розуміння EVM має вирішальне значення для підтримки смарт-контрактів у всій екосистемі блокчейну.
EVM — це віртуальна машина для децентралізованого виконання смарт-контрактів у мережі Ethereum. Багато блокчейнів, сумісних з EVM, використовують стандартні реалізації популярних клієнтів впровадження Ethereum різними мовами, такими як go-ethereum (Golang) і besu (Java), безпосередньо у своєму програмному забезпеченні протоколу.
Тим не менш, розгалуження та модифікація EVM насправді є досить поширеним явищем в екосистемі блокчейну, навіть у межах основних протоколів. Наприклад, Optimism Bedrock Stack, який «забезпечує» блокчейн Base L2 Coinbase, використовує форк клієнта виконання go-ethereum під назвою op-geth, який запускає ту саму EVM, що й популярний клієнт виконання Ethereum. Однак це не означає, що EVM на Ethereum поводиться точно так само, як EVM на Optimism: у деяких випадках op-geth EVM поводиться дещо по-іншому (тобто СКЛАДНІСТЬ повернення випадкових значень визначається секвенсором).
Хоча це звучить страшно, це загалом корисно для впровадження EVM. Хоча стандартна реалізація EVM оптимізована для базового протоколу Ethereum, розгалужені EVM часто розширюють її для нових власних протоколів. Як наслідок, контракти можуть виконуватися по-іншому в деяких ланцюжках, сумісних з EVM, ніж в Ethereum, а припущення щодо безпеки поведінки смарт-контракту EVM також можуть значно відрізнятися між різними протоколами.
Форк системи безпеки EVM
З цією метою Coinbase розробила структуру безпеки Web3 для оцінки впливу на безпеку деяких роздвоєних реалізацій EVM. Ми називаємо це розгалуженою структурою EVM Coinbase, яка буде детально описана нижче.
За допомогою цієї розгалуженої системи безпеки EVM Coinbase може ефективно:
Розуміння недійсності припущень про безпеку нашої фреймворку токенів Ethereum дозволяє безпечно вмикати нові блокчейни, сумісні з EVM, для підтримки токенів ERC-20/ERC-721 на наших децентралізованих біржах;
Надайте аудиторам смарт-контрактів аналіз ситуації вразливості смарт-контракту форкованої EVM, особливо невеликі відмінності в міжмережевих мережах;
Забезпечте безпечне використання та виконання смарт-контрактів EVM на блокчейні Base L2 Coinbase.
Стандарт безпеки для EVM-сумісних блокчейнів
Щоб зрозуміти, як існують ризики безпеки у віртуальній машині Ethereum, ми повинні спочатку знати, які гарантії надає нам стандартна реалізація EVM. Ми визначаємо стандартний EVM як EVM, який постійно використовується клієнтами виконання валідатора Ethereum, як описано в Специфікації реалізації Ethereum. Найбільш використовуваним клієнтом є go ethereum (тобто geth).
Ми підсумовуємо безпеку за двома критеріями безпеки, які представляють мінімальні вимоги до будь-якої розгалуженої реалізації EVM, щоб мати право на підтримку Coinbase.
Як ми перевіряємо ризики безпеки впровадження EVM?
Наша розгалужена структура EVM зосереджується на наступних вимогах аудиту під час оцінки відповідності загальним критеріям безпеки (тобто незмінність контракту та безпечне середовище виконання). Слід зазначити, що наступні компоненти ризику не є повним обсягом аудиту fork EVM.
Зміна визначення та кодування кодів операцій EVM може призвести до значних відмінностей у тому, як виконуються контракти. Наприклад, припустимо, що деяка роздвоєна реалізація EVM (EVM') змінює арифметичний код операції ADD, щоб визначити логіку (x1 + x2) для віднімання двох значень (x1 - x2).
Як наслідок, відхилений EVM' є нерівним і несумісним у виконанні зі стандартним EVM. Наслідками модифікації кодів операцій може бути корисна поведінка, наприклад запобігання цілочисельного переповнення та недоповнення в арифметичних кодах операцій, або більш небезпечна поведінка, наприклад поведінка самознищення, яка спричиняє нескінченне карбування локальних активів.
EVM використовує попередньо скомпільовані контракти для визначення складних функцій (таких як функції шифрування), використовуючи більш зручну та продуктивну мову, таку як Golang, замість використання менш доступного байт-коду EVM.
По суті, це запрограмовані функції, доступ до яких здійснюється через заздалегідь визначені ланцюгові адреси, представлені в програмному забезпеченні вузла. Є 9 прекомпіляторів, визначених у жовтій книзі Ethereum (станом на травень 2023 року), і будь-які зміни в цих 9 прекомпіляторах або введення нових прекомпіляторів потрібно перевіряти.
Візьмемо інший конкретний приклад — уразливість BNB Smart Chain. BNB Smart Chain використовує відхилену реалізацію go-ethereum для запуску вузлів. З цією метою представлено два нові попередньо скомпільовані контракти (tmHeaderValidate, iavlMerkleProofValidate) для використання стороннього програмного забезпечення (тобто Cosmos SDK) для виконання легкої перевірки клієнтських блоків і перевірки Merkle. Проблема полягає в тому, що програмне забезпечення Cosmos SDK має помилку реалізації у представленні дерева IAWL, яка дозволяє криптографічно недійсним доказам проходити перевірку. Іншими словами, будь-хто може генерувати гроші з повітря. Зловмисники змогли використати цю помилку реалізації, вкладену в попередній компілятор iavlMerkleProofValidate, щоб перекачати сотні мільйонів доларів із міжланцюжкового мосту Binance.
Цей приклад експлойту призначений для демонстрації необхідності безпеки прекомпілятора та потенційних ризиків впровадження нових попередньо скомпільованих контрактів для відхиляючих реалізацій EVM.
Потенційно фатальні ризики введення додаткових прекомпіляторів включають:
Дозволити одній стороні в односторонньому порядку змінювати стан будь-якого розгорнутого контракту;
Сюди входять усі модифікації сховища (вставки, оновлення, видалення);
використання ненадійних, неперевірених або неперевірених залежностей третіх сторін;
Надає доступ до значення в невизначеному вузлі.
Незважаючи на те, що компілятор і EVM розглядаються як абсолютно окремі сутності, варто зазначити, що компілятор Solidity робить суворі припущення щодо поведінки перших трьох попередньо скомпільованих контрактів (ecrecover, sha256 і &ripemd), які передаються через Solidity. Функція ключового слова рідної мови представлення в мові. За лаштунками компілятор Solidity фактично обробляє ці ключові слова в байт-код, який виконує статичні виклики між контрактами. Діаграма нижче додатково ілюструє цей спосіб зв’язку між контрактами.
Ризики безпеки, пов’язані зі зміною стандартного прекомпілятора, включають:
Дозволити централізованим контрагентам в односторонньому порядку змінювати стан будь-якого розгорнутого контракту;
Сюди входять усі модифікації сховища (вставки, оновлення, видалення);
Припущення щодо попередньої компіляції компілятора Solidity є суперечливим;
Надає доступ до значень всередині невизначених вузлів;
Використання ненадійних, неперевірених або неперевірених залежностей третіх сторін.
Основні ризики, пов’язані зі зміною основних компонентів EVM, включають:
не обмежує нескінченно великий стек інтерпретатора;
Зміна розміру або зміна моделі пам'яті може призвести до недетермінованого виконання;
Обхід контролю доступу, дозволяючи будь-якому контрагенту в односторонньому порядку отримати доступ до всіх станів ланцюга;
Використання ненадійних, неперевірених або неперевірених залежностей третіх сторін.
Чому ми повинні звертати увагу на безпеку EVM?
Наша мета — побудувати відкриту фінансову систему на основі технології блокчейн, і з цією метою ми заохочуємо розробку різних реалізацій EVM. Однак для того, щоб блокчейн, сумісний з EVM, повністю підтримувався Coinbase, він повинен відповідати основним вимогам стандартної реалізації EVM. Цей документ має на меті підвищити обізнаність про ризики, пов’язані з відхиленням від EVM, і заохотити емітентів активів віддавати пріоритет розробці безпечних компонентів при відхиленні від EVM, підвищуючи обізнаність про безпеку в усій екосистемі Web3.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Як оцінити ризик безпеці «роздвоєного EVM»?
Оригінальна назва: «Як використовувати Forked EVM для ризиків безпеки»
Автори: Ітан Поціаск, Ерік Менг, Надір Ахтар, Габріела Мелендес Куан, Том Райан
Упорядник: Katie Koo
Щоб посилити гарантії безпеки та зберігання для клієнтів, які торгують ERC-20 та іншими активами на основі смарт-контрактів, команда Coinbase Blockchain Security дослідила програмний рівень, який визначає поведінку цих активів: віртуальну машину Ethereum (EVM). Під час оцінки проектів, які змінюють EVM їхньої власної мережі, команда безпеки блокчейну Coinbase переглядає ключові зміни EVM, щоб визначити, чи може модифікована EVM забезпечити таку саму безпеку та гарантії зберігання, як оригінальна реалізація EVM.
Статус форка EVM
Станом на травень 2023 року віртуальна машина Ethereum (EVM) отримала титул «Великого брата» найпопулярнішої платформи для виконання смарт-контрактів. За даними DefiLlama, 9 із 10 найкращих мереж за Total Value Locked (TVL) підтримують смарт-контракти EVM. Тому глибоке розуміння EVM має вирішальне значення для підтримки смарт-контрактів у всій екосистемі блокчейну.
EVM — це віртуальна машина для децентралізованого виконання смарт-контрактів у мережі Ethereum. Багато блокчейнів, сумісних з EVM, використовують стандартні реалізації популярних клієнтів впровадження Ethereum різними мовами, такими як go-ethereum (Golang) і besu (Java), безпосередньо у своєму програмному забезпеченні протоколу.
Тим не менш, розгалуження та модифікація EVM насправді є досить поширеним явищем в екосистемі блокчейну, навіть у межах основних протоколів. Наприклад, Optimism Bedrock Stack, який «забезпечує» блокчейн Base L2 Coinbase, використовує форк клієнта виконання go-ethereum під назвою op-geth, який запускає ту саму EVM, що й популярний клієнт виконання Ethereum. Однак це не означає, що EVM на Ethereum поводиться точно так само, як EVM на Optimism: у деяких випадках op-geth EVM поводиться дещо по-іншому (тобто СКЛАДНІСТЬ повернення випадкових значень визначається секвенсором).
Хоча це звучить страшно, це загалом корисно для впровадження EVM. Хоча стандартна реалізація EVM оптимізована для базового протоколу Ethereum, розгалужені EVM часто розширюють її для нових власних протоколів. Як наслідок, контракти можуть виконуватися по-іншому в деяких ланцюжках, сумісних з EVM, ніж в Ethereum, а припущення щодо безпеки поведінки смарт-контракту EVM також можуть значно відрізнятися між різними протоколами.
Форк системи безпеки EVM
З цією метою Coinbase розробила структуру безпеки Web3 для оцінки впливу на безпеку деяких роздвоєних реалізацій EVM. Ми називаємо це розгалуженою структурою EVM Coinbase, яка буде детально описана нижче.
За допомогою цієї розгалуженої системи безпеки EVM Coinbase може ефективно:
Стандарт безпеки для EVM-сумісних блокчейнів
Щоб зрозуміти, як існують ризики безпеки у віртуальній машині Ethereum, ми повинні спочатку знати, які гарантії надає нам стандартна реалізація EVM. Ми визначаємо стандартний EVM як EVM, який постійно використовується клієнтами виконання валідатора Ethereum, як описано в Специфікації реалізації Ethereum. Найбільш використовуваним клієнтом є go ethereum (тобто geth).
Ми підсумовуємо безпеку за двома критеріями безпеки, які представляють мінімальні вимоги до будь-якої розгалуженої реалізації EVM, щоб мати право на підтримку Coinbase.
Як ми перевіряємо ризики безпеки впровадження EVM?
Наша розгалужена структура EVM зосереджується на наступних вимогах аудиту під час оцінки відповідності загальним критеріям безпеки (тобто незмінність контракту та безпечне середовище виконання). Слід зазначити, що наступні компоненти ризику не є повним обсягом аудиту fork EVM.
Зміна визначення та кодування кодів операцій EVM може призвести до значних відмінностей у тому, як виконуються контракти. Наприклад, припустимо, що деяка роздвоєна реалізація EVM (EVM') змінює арифметичний код операції ADD, щоб визначити логіку (x1 + x2) для віднімання двох значень (x1 - x2).
Як наслідок, відхилений EVM' є нерівним і несумісним у виконанні зі стандартним EVM. Наслідками модифікації кодів операцій може бути корисна поведінка, наприклад запобігання цілочисельного переповнення та недоповнення в арифметичних кодах операцій, або більш небезпечна поведінка, наприклад поведінка самознищення, яка спричиняє нескінченне карбування локальних активів.
EVM використовує попередньо скомпільовані контракти для визначення складних функцій (таких як функції шифрування), використовуючи більш зручну та продуктивну мову, таку як Golang, замість використання менш доступного байт-коду EVM.
По суті, це запрограмовані функції, доступ до яких здійснюється через заздалегідь визначені ланцюгові адреси, представлені в програмному забезпеченні вузла. Є 9 прекомпіляторів, визначених у жовтій книзі Ethereum (станом на травень 2023 року), і будь-які зміни в цих 9 прекомпіляторах або введення нових прекомпіляторів потрібно перевіряти.
Візьмемо інший конкретний приклад — уразливість BNB Smart Chain. BNB Smart Chain використовує відхилену реалізацію go-ethereum для запуску вузлів. З цією метою представлено два нові попередньо скомпільовані контракти (tmHeaderValidate, iavlMerkleProofValidate) для використання стороннього програмного забезпечення (тобто Cosmos SDK) для виконання легкої перевірки клієнтських блоків і перевірки Merkle. Проблема полягає в тому, що програмне забезпечення Cosmos SDK має помилку реалізації у представленні дерева IAWL, яка дозволяє криптографічно недійсним доказам проходити перевірку. Іншими словами, будь-хто може генерувати гроші з повітря. Зловмисники змогли використати цю помилку реалізації, вкладену в попередній компілятор iavlMerkleProofValidate, щоб перекачати сотні мільйонів доларів із міжланцюжкового мосту Binance.
Цей приклад експлойту призначений для демонстрації необхідності безпеки прекомпілятора та потенційних ризиків впровадження нових попередньо скомпільованих контрактів для відхиляючих реалізацій EVM.
Потенційно фатальні ризики введення додаткових прекомпіляторів включають:
Незважаючи на те, що компілятор і EVM розглядаються як абсолютно окремі сутності, варто зазначити, що компілятор Solidity робить суворі припущення щодо поведінки перших трьох попередньо скомпільованих контрактів (ecrecover, sha256 і &ripemd), які передаються через Solidity. Функція ключового слова рідної мови представлення в мові. За лаштунками компілятор Solidity фактично обробляє ці ключові слова в байт-код, який виконує статичні виклики між контрактами. Діаграма нижче додатково ілюструє цей спосіб зв’язку між контрактами.
Ризики безпеки, пов’язані зі зміною стандартного прекомпілятора, включають:
Основні ризики, пов’язані зі зміною основних компонентів EVM, включають:
Чому ми повинні звертати увагу на безпеку EVM?
Наша мета — побудувати відкриту фінансову систему на основі технології блокчейн, і з цією метою ми заохочуємо розробку різних реалізацій EVM. Однак для того, щоб блокчейн, сумісний з EVM, повністю підтримувався Coinbase, він повинен відповідати основним вимогам стандартної реалізації EVM. Цей документ має на меті підвищити обізнаність про ризики, пов’язані з відхиленням від EVM, і заохотити емітентів активів віддавати пріоритет розробці безпечних компонентів при відхиленні від EVM, підвищуючи обізнаність про безпеку в усій екосистемі Web3.