Я верю, что Uniswap v4 скоро станет доступен каждому!

На этот раз команда Uniswap ставит амбициозные цели и планирует представить множество новых функций [1], включая поддержку неограниченного количества пулов ликвидности и динамические комиссии для каждой торговой пары, дизайн Singleton, молниеносный учет, хуки и поддержку токена ERC1155. стандарт. Ожидается, что Uniswap v4, использующий временное хранилище, представленное EIP-1153, будет выпущен после обновления Ethereum Cancun.

Среди многих инноваций механизм «Хук» привлек широкое внимание благодаря своему мощному потенциалу. Механизм Hook поддерживает выполнение определенного кода в определенные моменты жизненного цикла пула ликвидности, что значительно повышает масштабируемость и гибкость пула. Однако крючковый механизм также может оказаться палкой о двух концах. Хотя он мощный и гибкий, безопасное использование Hook также является большой проблемой.

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

1 - Механизм Uniswap V4

Прежде чем углубиться в это, нам необходимо иметь общее представление о механизме Uniswap v4.

Согласно официальному объявлению [1] и официальному документу [2], хуки, одноэлементная архитектура и молниеносный учет являются тремя важными функциями для реализации пользовательских пулов ликвидности и достижения эффективной маршрутизации между несколькими пулами. 1.1 HookHook относится к контрактам, которые выполняются на разных этапах жизненного цикла пула ликвидности.Команда Uniswap надеется дать возможность каждому принимать компромиссные решения, вводя крючки. Таким образом, можно изначально поддерживать динамические комиссии, добавлять ордера с ограничением по цепочке или распределять крупные ордера через средневзвешенного по времени маркет-мейкера (TWAMM).

В настоящее время существует восемь обратных вызовов Hook, разделенных на четыре группы (каждая группа содержит пару обратных вызовов):

- до инициализации/после инициализации

- beforeModifyPosition/afterModifyPosition

- до замены/после замены

- допожертвования/послепожертвования

Ниже приводится процесс обмена хуками, представленный в официальном документе [2].

- до замены/после замены

- допожертвования/послепожертвования

Ниже приводится процесс обмена хуками, представленный в официальном документе [2].

Рисунок 1: Процесс замены крючка

Команда Uniswap представила метод работы на некоторых примерах (например, TWAMM Hook[3]), а участники сообщества также внесли свой вклад. В официальной документации[4] также имеется ссылка на репозиторий Awesome Uniswap v4 Hooks[5], в котором собрано больше примеров Hook.

1.2 Синглтон, молниеносный учет и механизм блокировки

Архитектура Singleton и флэш-учет предназначены для повышения производительности за счет снижения затрат и обеспечения эффективности. Он вводит новый одноэлементный контракт, в котором все пулы ликвидности хранятся в одном смарт-контракте. Эта одноэлементная конструкция использует PoolManager для хранения и управления состоянием всех пулов.

В более ранних версиях протокола Uniswap такие операции, как обмен или добавление ликвидности, включали прямую передачу токенов.Версия v4 отличается тем, что в ней реализован молниеносный учет и механизм блокировки.

Механизм блокировки работает следующим образом:

1. Контракт шкафчика запрашивает блокировку PoolManager.

2. PoolManager добавляет адрес контракта шкафчика в очередь lockData и вызывает обратный вызов lockAcquired.

3. Контракт шкафчика выполняет свою логику в обратном вызове. Во время исполнения взаимодействие контракта шкафчика с пулом может привести к ненулевому приращению валюты. Однако в конце выполнения все дельты должны обнулиться. Кроме того, если очередь lockData не пуста, только последний контракт шкафчика может выполнять операции.

4. PoolManager проверяет состояние очереди lockData и приращение валюты. После проверки PoolManager удалит контракт шкафчика. Таким образом, механизм блокировки предотвращает одновременный доступ и гарантирует очистку всех транзакций. Контракт шкафчика применяется к последовательным блокировкам, а затем выполняет транзакции через обратный вызов lockAcquired. Соответствующий обратный вызов Hook будет запускаться до и после каждой операции пула. Наконец, PoolManager проверяет статус.

Этот подход означает, что операция корректирует внутренний чистый баланс (т. е. дельту), а не выполняет мгновенный перевод. Любые изменения будут записаны во внутреннем балансе пула, а фактическая передача будет произведена в конце операции (т. е. блокировки). Этот процесс гарантирует отсутствие непогашенных токенов, тем самым сохраняя целостность средств.

Из-за механизма блокировки внешние учетные записи (EOA) не могут напрямую взаимодействовать с PoolManager. Вместо этого любое взаимодействие должно происходить посредством контракта. Этот контракт действует как промежуточный блокировщик и должен запрашивать блокировку перед выполнением каких-либо операций с пулом.

Существует два основных сценария взаимодействия контрактов:

Определенный контракт шкафчика берется из официальной базы кода или развертывается пользователями. В этом случае мы можем думать о взаимодействии как о проходящем через маршрутизатор.

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

2 – Модель угроз

Прежде чем обсуждать связанные с этим вопросы безопасности, нам необходимо определить модель угроз. В основном мы рассматриваем следующие две ситуации:

Модель угрозы I. Сами по себе хуки безопасны, но имеют уязвимости.

Модель угрозы II: Хуки по своей сути вредоносны.

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

Модель угрозы I. Сами по себе хуки безопасны, но имеют уязвимости.

Модель угрозы II: Хуки по своей сути вредоносны.

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

2.1 Проблемы безопасности в модели угроз I

Модель угроз I фокусируется на уязвимостях, связанных с самим хуком. Эта модель угроз предполагает, что разработчики и их крючки безвредны. Однако в хуках могут появиться и существующие известные уязвимости в смарт-контрактах. Например, если Hook реализован как обновляемый контракт, он может столкнуться с проблемами, связанными с уязвимостью UUPSUpgradeable в OpenZeppelin.

Учитывая вышеперечисленные факторы, мы решили сосредоточиться на потенциальных уязвимостях, характерных для версии v4. В Uniswap v4 хуки — это смарт-контракты, которые могут выполнять пользовательскую логику до или после операций основного пула (включая инициализацию, изменение позиции, замену и сбор). Хотя ожидается, что хуки будут реализовывать стандартные интерфейсы, они также позволяют включать пользовательскую логику. Поэтому наше обсуждение будет ограничено логикой, включающей стандартный интерфейс Hook. Затем мы попытаемся определить возможные источники уязвимостей, например, как хуки могут злоупотреблять этими стандартными функциями хуков.

В частности, мы сосредоточимся на следующих двух типах хуков:

Первый тип крючка — удержание средств пользователя. В этом случае злоумышленник может атаковать этот хук для перевода средств, что приведет к потере активов.

Второй тип перехватчика хранит ключевые данные о состоянии, на которые полагаются пользователи или другие протоколы. В этом случае злоумышленник может попытаться изменить критическое состояние. Потенциальные риски могут возникнуть, когда неправильное состояние используется другими пользователями или протоколами.

Обратите внимание, что хуки, выходящие за рамки этих двух областей, выходят за рамки нашего обсуждения. Поскольку на момент написания статьи реальных вариантов использования хуков не было, мы возьмем некоторую информацию из репозитория Awesome Uniswap v4 Hooks. После углубленного изучения репозитория Awesome Uniswap v4 Hooks (хеш коммита 3a0a444922f26605ec27a41929f3ced924af6075) мы обнаружили несколько критических уязвимостей. Эти уязвимости в основном возникают из-за рискованных взаимодействий между перехватчиками, PoolManager и внешними третьими лицами, и их можно разделить на две категории: проблемы контроля доступа и проблемы проверки ввода. Пожалуйста, смотрите таблицу ниже для получения конкретных результатов:

Всего мы нашли 22 соответствующих проекта (не считая проектов, не связанных с Uniswap v4). Из этих проектов мы считаем, что 8 (36%) являются уязвимыми. Из восьми уязвимых проектов шесть имели проблемы с контролем доступа, а два были уязвимы для ненадежных внешних вызовов.

2.1.1 Проблемы контроля доступа

В этой части обсуждения мы в основном фокусируемся на проблемах, которые могут быть вызваны функциями обратного вызова в версии 4, включая 8 обратных вызовов-перехватчиков и обратные вызовы блокировок. Конечно, есть и другие ситуации, которые необходимо проверить, но эти ситуации различаются по дизайну и выходят за рамки нашего обсуждения.

Эти функции должны вызываться только PoolManager и не могут вызываться по другим адресам (включая EOA и контракты). Например, в случае, когда вознаграждения распределяются по ключам пула, вознаграждения могут быть затребованы некорректно, если соответствующая функция может быть вызвана любой учетной записью.

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

2.1.2 Вопросы для проверки ввода

В Uniswap v4 из-за механизма блокировки пользователи должны получить блокировку через контракт, прежде чем выполнять какие-либо операции с пулом средств. Это гарантирует, что контракт, который в данный момент участвует во взаимодействии, является последним контрактом шкафчика. Тем не менее, все еще существует возможный сценарий атаки, а именно ненадежные внешние вызовы из-за неправильной проверки ввода в некоторых уязвимых реализациях перехватчиков:

В Uniswap v4 из-за механизма блокировки пользователи должны получить блокировку через контракт, прежде чем выполнять какие-либо операции с пулом средств. Это гарантирует, что контракт, который в данный момент участвует во взаимодействии, является последним контрактом шкафчика. Тем не менее, все еще существует возможный сценарий атаки, а именно ненадежные внешние вызовы из-за неправильной проверки ввода в некоторых уязвимых реализациях перехватчика:

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

Во-вторых, некоторые функции перехвата клавиш допускают произвольные внешние вызовы.

Недоверенные внешние вызовы чрезвычайно опасны, поскольку могут привести к различным типам атак, включая так называемые атаки повторного входа. Чтобы атаковать эти уязвимые перехватчики, злоумышленник может зарегистрировать вредоносный пул средств для своих собственных поддельных токенов, а затем вызвать перехват для выполнения операций в пуле средств. При взаимодействии с пулом логика вредоносного токена перехватывает поток управления, вызывая нежелательное поведение.

2.1.3 Превентивные меры против модели угроз I

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

2.2 Проблемы безопасности в модели угроз II

В этой модели угроз мы предполагаем, что разработчик и его крючок являются злонамеренными. Из-за широкого охвата мы фокусируемся только на вопросах безопасности, связанных с версией v4. Таким образом, ключевой момент заключается в том, может ли предоставленный крючок обрабатывать криптоактивы, переданные или авторизованные пользователем. Поскольку метод доступа к хуку определяет разрешения, которые могут быть предоставлены хуку, мы делим хуки на две категории:

Управляемые перехватчики. Перехватчики не являются точками входа. Пользователи должны взаимодействовать с перехватчиком через маршрутизатор (возможно, предоставленный Uniswap).

Автономные хуки. Хуки — это точки входа, которые позволяют пользователям напрямую взаимодействовать с ними.

Рисунок 2. Пример вредоносного перехватчика.

2.2.1 Управляемый хук

В этом случае криптоактивы пользователя (включая собственные токены и другие токены) передаются или авторизуются на маршрутизаторе. Поскольку PoolManager выполняет проверку баланса, злонамеренным перехватчикам нелегко напрямую украсть эти активы. Однако потенциальная поверхность атаки все еще существует. Например, механизм управления расходами версии v4 может быть использован злоумышленниками с помощью перехватчиков.

2.2.2 Независимый хук Когда хук используется в качестве точки входа, ситуация усложняется.

В этом случае хук приобретает большую силу, поскольку пользователь может взаимодействовать с ним напрямую. Теоретически хук может делать с этим взаимодействием все, что захочет. В версии v4 очень важна проверка логики кода. Основной вопрос заключается в том, можно ли манипулировать логикой кода. Если перехват можно обновить, это означает, что, казалось бы, безопасный перехват может стать вредоносным после обновления, что представляет значительный риск. Эти риски включают в себя:

Обновляемые агенты (могут быть атакованы напрямую);

С логикой самоуничтожения. Возможна атака в случае совместных вызовов самоуничтожения и создания2.

2.2.3 Превентивные меры против модели угроз II

Обновляемые агенты (могут быть атакованы напрямую);

С логикой самоуничтожения. Возможна атака в случае совместных вызовов самоуничтожения и создания2.

2.2.3 Превентивные меры против модели угроз II

Крайне важно оценить, является ли хук вредоносным. В частности, для управляемых перехватчиков мы должны сосредоточиться на поведении управления затратами; в то время как для независимых перехватчиков основное внимание уделяется возможности их обновления. - 3 -Заключение В этой статье мы сначала кратко описываем основные механизмы, связанные с проблемами безопасности Hook в Uniswap v4. Впоследствии мы предлагаем две модели угроз и кратко описываем связанные с ними риски безопасности. В последующих статьях мы проведем углубленный анализ проблем безопасности по каждой модели угроз. Следите за обновлениями!