Почему большинство смарт -инструментов анализа контракта не проходят при проверке адреса
15 июля 2025 г.Таблица ссылок
Аннотация и 1. Введение
Фон
2.1 Ethereum Primer
2.2 Проверка адреса белого списка
2.3 Анализ Taint по интеллектуальным контрактам и 2,4 модели угрозы
Мотивирующий пример и проблемы
3.1 Мотивирующий пример
3.2 Проблемы
3.3 Ограничения существующих инструментов
Дизайн Avverifier и 4.1 Обзор
4.2 обозначения
4.3 Компонент № 1: График кода
4.4 Компонент № 2: симулятор EVM
4.5 Компонент № 3: детектор уязвимости
Оценка
5.1 Экспериментальная настройка и исследовательские вопросы
5.2 RQ1: эффективность и эффективность
5.3 RQ2: характеристики уязвимых контрактов реального мира
5.4 RQ3: обнаружение в реальном времени
Дискуссия
6.1 Угрозы для достоверности и 6.2 ограничения
6.3 Этическое рассмотрение
Связанная работа
Заключение, доступность и ссылки
3.3 Ограничения существующих инструментов
Учитывая цель реализации легкого и эффективного детектора для уязвимости проверки адреса, мы исключаем анализаторов, которые принимают динамический анализ. Причины этого решения являются двойными. С одной стороны, динамический анализ требует среды выполнения для выполнения, которая является ресурсной и трудоемкой, в отличие от нашей легкой цели. С другой стороны, динамический анализ идентифицирует уязвимости с генерируемыми тестовыми случаями и оракулами. Для замысловатых контрактов, особенно для межконтрактного анализа, этот метод не всегда может охватывать все уязвимые пути, что может привести к ложным негативам. Следовательно, рассматриваются статические методы, включаяСоответствие на основе шаблонов, символическое выполнение и анализ Daint. Насколько нам известно, существующие инструменты не могут быть непосредственно развернуты для обнаружения этой уязвимости.Хотя мы можем расширить их с помощью способности обнаружить уязвимость, мы наблюдаем некоторые внутренние ограничения.
Сопоставление на основе шаблонов.Это опирается на эвристические правила, обобщенные разработчиками. Многие предварительные инструменты используют этот метод, выявляя уязвимости в соответствии с последовательностями OPCODE [37], истории транзакций [5] и следы вызова [23]. Однако такой ручной процесс невыражен и подвержен ошибкам, который даже не может обрабатыватьC1, то есть идентификация семантики последовательностей байт -кодов. Следовательно, постоянное обновление синтаксиса прочности [75] и компиляционного инструмента [30] делает такого рода анализаторы неэффективными.
Символическое исполнение и проверка модели.Оба метода широко используются в выявлении уязвимостей при анализе программного обеспечения. Принимая преимущества абстракции программ, символические исполнители и модельные контролировки могут восстановить некоторую семантическую информацию для преодоленияC1Полем Тем не менее, они по своей природе ограничены проблемой эффективности, в основном вызванной взрывом пути/состояния. Например, при рассмотрении примера, показанного в листинге 3, оба они должны не только пройти все возможные функции через запись, чтобы найти депозитные функции, но и застрять от L16 до L18, где они будут пробовать все возможные контракты. Потому что они не могут эффективно и эффективно проводить межконтракт или даже межпроцедурный анализ,C2является основным вызовом Hiders, их принятие. Более того, они пытаются точно смоделировать область памяти точным образом, то есть, учитывая все в памяти. Несмотря на то, что такое точное моделирование пользуется обоснованностью анализа результатов, это происходит за счет эффективности. В контексте уязвимости проверки адреса нам нужно только сосредоточиться на распространении параметров адреса в области памяти вместо конкретных данных.
Половный анализ.Существующие анализаторы Daint не могут быть непосредственно приняты для определения этой уязвимости. Во -первых, некоторые из них полагаются на исходный код [31]. В Ethereum такие контракты составляют только 1%. Во -вторых, некоторые из них ограничены их принятыми методами при сборе информации о распространении зажатия и отслеживанием размножения. Например, Sereum [66] использует динамический анализ для мониторинга выполнения во время выполнения. Кроме того, Mythril [70] и Osiris [73] оба принимают символическое исполнение для статического сбора информации. Mythril пытается пройти все возможные пути, в то время как Осирис только внутрипроцедуральный. Ethainter [14] является сильным соперником. Тем не менее, это демонстрирует мастерство в решении решенияC1иC2, но это страдает из -за тонкостей линейной модели памяти EVM. В частности, он не может должным образом обрабатывать динамические распределения памяти и сделки в памяти EVM, которая потенциально ставит под угрозу точность его отслеживания разрушения, особенно когда контракты выполняют сложные операции памяти или используют память для хранения и манипулирования промежуточными данными (например, три механизма проверки памяти, упомянутые в §2.2).
Наша ключевая идея.Как вызывает вышеупомянутое, символическое выполнение и анализ Deaint могут эффективно восстановить семантику и в некоторой степени провести межпроцедурный анализ при контрольном потоке и зависимостях потока данных. Однако, учитывая обоснованность анализа, символическое исполнение всегда страдает от проблемы эффективности. С этой целью мы решили усыновитьАнализ Static EVM на основе моделирования EVM, который отслеживает размножение с запахом посредством статического моделирования на байт -коде. Чтобы уменьшить ложные срабатывания, введенные в результате статического моделирования и отфильтровать пути, которые могут привести к эксплуатации, мы разрабатываем детектор с тройками, соответствующий трем принципам, упомянутым в §3.1. Более того, чтобы преодолеть проблему памяти, пострадавшую от Ethainter, мы решаем разработать модель памяти, мотивированную He et al. [41], чтобы абстрагировать разреженную линейную память в пары клавиш. Следовательно, наш дизайн может решать как C1, так и C2. Кроме того, Avverifier имитирует стек и память через самовнимательный симулятор EVM для захвата распространения адресов, обеспечивая эффективность не динамических данных. Что касается динамических параметров памяти, Avverifier консервативно рассматривает их как символы и гарантирует только баланс стека, чтобы избежать негативного влияния, оказываемого путем перечисления всех возможных значений.
Авторы:
(1) Tianle Sun, Университет науки и техники Хуажонга;
(2) Ningyu HE, Peking University;
(3) Цзян Сяо, Университет науки и техники Хуажонга;
(4) Yinliang Yue, лаборатория Zhongguancun;
(5) Сяпу Луо, Гонконгский политехнический университет;
(6) Хаою Ван, Университет науки и техники Хуажонга.
Эта статья есть
Оригинал