Как оценить риск безопасности «форка EVM»?

9 из 10 ведущих сетей TVL поддерживают смарт-контракты EVM.

Исходное название: «Как использовать разветвленные EVM для угроз безопасности»

撰文：Итан Посиаск, Эрик Менг, Надир Ахтар, Габриэла Мелендес Куан, Том Райан

Составитель: Кэти Ку

Чтобы усилить гарантии безопасности и хранения для клиентов, торгующих ERC-20 и другими активами на основе смарт-контрактов, команда Coinbase Blockchain Security исследовала программный уровень, который определяет поведение этих активов: виртуальную машину Ethereum (EVM). При оценке проектов, которые модифицируют EVM своей собственной сети, группа безопасности блокчейна Coinbase анализирует ключевые изменения EVM, чтобы определить, может ли модифицированный EVM обеспечить те же гарантии безопасности и хранения, что и исходная реализация EVM.

Статус форка EVM

По состоянию на май 2023 года виртуальная машина Ethereum (EVM) завоевала титул «старшего брата» самой популярной платформы для исполнения смарт-контрактов. По данным DefiLlama, 9 из 10 ведущих цепочек по общей заблокированной стоимости (TVL) поддерживают смарт-контракты EVM. Поэтому глубокое понимание EVM имеет решающее значение для поддержки смарт-контрактов во всей экосистеме блокчейна.

EVM — это виртуальная машина для децентрализованного исполнения смарт-контрактов в сети Ethereum. Многие EVM-совместимые блокчейны используют стандартные реализации популярных клиентов реализации Ethereum на разных языках, таких как go-ethereum (Golang) и besu (Java), непосредственно в своем протокольном программном обеспечении.

Тем не менее, разветвление и модификация EVM на самом деле довольно распространены в экосистеме блокчейна, даже в рамках основных протоколов. Например, стек Optimism Bedrock, который «поддерживает» блокчейн Coinbase Base L2, использует форк клиента выполнения go-ethereum под названием op-geth, который запускает тот же EVM, что и популярный клиент исполнения ethereum. Однако это не означает, что EVM на Ethereum ведет себя точно так же, как EVM на Optimism: EVM op-geth в некоторых случаях ведет себя несколько иначе (т.е. СЛОЖНОСТЬ возврата случайных значений определяется секвенсором).

Хотя это звучит пугающе, в целом это полезно для внедрения EVM. В то время как стандартная реализация EVM оптимизирована для базового протокола Ethereum, разветвленные EVM часто расширяют ее для новых собственных протоколов. В результате контракты могут выполняться по-разному в некоторых цепочках, совместимых с EVM, чем в Ethereum, и предположения о безопасности поведения смарт-контрактов EVM также могут сильно различаться между различными протоколами.

Создайте форк системы безопасности EVM

С этой целью Coinbase разработала структуру безопасности Web3 для оценки влияния на безопасность некоторых разветвленных реализаций EVM. Мы называем это разветвленной структурой EVM Coinbase, которая будет подробно объяснена ниже.

Благодаря этой разветвленной структуре безопасности EVM Coinbase может эффективно:

• Понимание недействительности предположений о безопасности нашей структуры токенов Ethereum позволяет нам безопасно включать новые EVM-совместимые блокчейны для поддержки токенов ERC-20/ERC-721 на наших децентрализованных биржах;
• Предоставить аудиторам смарт-контрактов анализ ситуации уязвимости смарт-контрактов разветвленной EVM, особенно небольшие различия в кросс-сети;
• Обеспечьте безопасное использование и выполнение смарт-контрактов EVM на блокчейне Coinbase Base L2.

Стандарт безопасности для EVM-совместимых блокчейнов

Чтобы понять, как существуют риски безопасности в виртуальной машине Ethereum, мы должны сначала узнать, какие гарантии предоставляет нам стандартная реализация EVM. Мы определяем стандартную EVM как EVM, последовательно используемую клиентами исполнения валидатора Ethereum, как описано в Спецификации реализации Ethereum. Безусловно, наиболее часто используемым клиентом является go ethereum (т.е. geth).

Мы суммируем безопасность в два критерия безопасности, которые представляют собой минимальные требования для любой разветвленной реализации EVM, чтобы иметь право на поддержку Coinbase.

Как мы проверяем риски безопасности реализации EVM?

Наша разветвленная структура EVM фокусируется на следующих требованиях аудита при оценке соответствия общим критериям безопасности (т. е. неизменность контракта и безопасная среда выполнения). Следует отметить, что следующие компоненты риска не являются полным объемом аудита форка EVM.

Изменение определения и кодирования кодов операций EVM может привести к значительным различиям в том, как выполняются контракты. Например, предположим, что какая-то разветвленная реализация EVM (EVM’) изменяет арифметический код операции ADD, чтобы определить логику (x1 + x2) для вычитания двух значений (x1 - x2).

В результате отклоненный ЭВМ’ оказывается неравным и несовместимым по исполнению со стандартным ЭВМ. Последствиями изменения кодов операций могут быть полезные действия, такие как предотвращение целочисленного переполнения и потери значимости в арифметических кодах операций, или более опасное поведение, например поведение самоуничтожения, которое вызывает бесконечную чеканку локальных активов.

EVM использует предварительно скомпилированные контракты для определения сложных функций (таких как функции шифрования) с использованием более удобного и производительного языка, такого как Golang, вместо использования менее доступного байт-кода EVM.

По сути, это запрограммированные функции, доступ к которым осуществляется через предопределенные адреса цепочки, представленные в программном обеспечении узла. В «Желтой книге» Ethereum (по состоянию на май 2023 года) определено 9 прекомпиляторов, и любые изменения в этих 9 прекомпиляторах или введение новых прекомпиляторов необходимо проверять.

Возьмем другой конкретный пример — уязвимость BNB Smart Chain. BNB Smart Chain использует измененную реализацию go-ethereum для запуска узлов. С этой целью введены два новых предварительно скомпилированных контракта (tmHeaderValidate, iavlMerkleProofValidate) для использования стороннего программного обеспечения (например, Cosmos SDK) для выполнения легкой проверки клиентских блоков и проверки Меркла. Проблема заключается в том, что программное обеспечение Cosmos SDK имеет ошибку реализации в представлении дерева IAWL, которая позволяет криптографически недействительным доказательствам проходить проверку. Другими словами, каждый может делать деньги из воздуха. Злоумышленники смогли использовать эту уязвимость реализации, заложенную в прекомпиляторе iavlMerkleProofValidate, для перекачивания сотен миллионов долларов из кроссчейн-моста Binance.

Этот пример эксплойта предназначен для демонстрации необходимости безопасности прекомпилятора и потенциальных рисков введения новых предварительно скомпилированных контрактов для отклоняющихся реализаций EVM.

Потенциально фатальные риски внедрения дополнительных прекомпиляторов включают:

• Разрешить одной стороне в одностороннем порядке изменять состояние любого развернутого контракта;
• Сюда входят все модификации хранилища (вставки, обновления, удаления);
• использование ненадежных, непроверенных или непроверенных сторонних зависимостей;
• Предоставляет доступ к значению в неопределенном узле.

Несмотря на то, что компилятор и EVM рассматриваются как совершенно отдельные объекты, стоит отметить, что компилятор Solidity делает строгие предположения о поведении первых трех предварительно скомпилированных контрактов (ecrecover, sha256 и &ripemd), которые передаются через Solidity. представительство в языке. За кулисами компилятор Solidity фактически преобразует эти ключевые слова в байт-код, который выполняет статические вызовы между контрактами. Диаграмма ниже иллюстрирует этот способ связи между контрактами.

Угрозы безопасности, связанные с изменением стандартного прекомпилятора, включают:

• Разрешить централизованным контрагентам в одностороннем порядке изменять состояние любого развернутого контракта;
• Сюда входят все модификации хранилища (вставки, обновления, удаления);
• Предположение о позиции прекомпиляции компилятора Solidity противоречиво;
• Обеспечивает доступ к значениям внутри неопределенных узлов;
• Использование ненадежных, непроверенных или непроверенных сторонних зависимостей.

Основные риски, связанные с изменением основных компонентов EVM, включают:

• не ограничивает бесконечно большой стек интерпретатора;
• Изменение размера или модели памяти может привести к недетерминированному выполнению;
• Обход контроля доступа, позволяющий любому контрагенту в одностороннем порядке получить доступ ко всем состояниям цепочки;
• Использование ненадежных, непроверенных или непроверенных сторонних зависимостей.

Почему мы должны обращать внимание на безопасность EVM?

Наша цель — построить открытую финансовую систему на основе технологии блокчейн, и с этой целью мы поощряем разработку различных реализаций EVM. Однако для того, чтобы блокчейн, совместимый с EVM, полностью поддерживался Coinbase, он должен соответствовать основным требованиям стандартной реализации EVM. Этот документ призван повысить осведомленность о рисках, связанных с отклонением от EVM, и побудить эмитентов активов уделять приоритетное внимание разработке безопасных компонентов при отклонении от EVM, повышая осведомленность о безопасности во всей экосистеме Web3.