Тернии в розе: исследование рисков безопасности нового механизма хуков в Uniswap v4

Uniswap v4 уже в пути! Команда имеет амбициозные планы по внедрению ряда новых функциональных возможностей[1], включая (теоретически) неограниченное количество пулов и динамические ставки комиссий для каждой торговой пары, синглтон (singleton), флэш-бухгалтерию (flash accounting), хуки (hooks) и поддержку ERC1155. Используя транзитное хранилище (transient storage), представленное в EIP-1153, Uniswap v4, как ожидается, будет запущен после обновления Ethereum «Cancun».

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

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

Данная статья является первой в этой серии и предоставляет нашим читателям всесторонний обзор и фундаментальное понимание темы. Следите за обновлениями, чтобы не пропустить другие интересные дискуссии!

Механизм Uniswap v4

Прежде чем углубляться в детали, нам необходимо получить базовое представление о механизме Uniswap v4. Согласно официальному анонсу[1] и whitepaper[2], хуки, архитектура синглтона и флэш-бухгалтерия — это три ключевые функции, которые обеспечивают настройку пулов и эффективную маршрутизацию между множеством пулов.

Хуки

Хуки в v4 созданы для того, чтобы дать любому возможность принимать решения о компромиссах посредством хуков — контрактов, которые запускаются в различные моменты жизненного цикла действия пула. Благодаря этому можно создавать пулы, которые нативно поддерживают динамические комиссии, добавляют ончейн-лимитные ордера или действуют как маркет-мейкер средневзвешенной по времени цены (TWAMM) для распределения крупных ордеров во времени.

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

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate

Ниже показан поток свап-хуков, представленный в whitepaper[2].

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

Синглтон, флэш-бухгалтерия и механизм блокировки

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

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

Специфически, механизм блокировки работает следующим образом:

Контракт-локер (locker) запрашивает блокировку в PoolManager.
PoolManager добавляет адрес локера в очередь lockData и вызывает его callback-функцию lockAcquired.
Локер выполняет свою логику в callback-функции. Во время выполнения локера его взаимодействия с пулами могут привести к ненулевым дельтам валют. Однако к концу выполнения все дельты должны быть сведены к нулю. Кроме того, если очередь lockData не пуста, операции может выполнять только последний локер.
После этого PoolManager проверяет состояние очереди lockData и дельты валют. После проверки PoolManager удаляет локер.

В итоге, механизм блокировки предотвращает одновременный доступ и обеспечивает расчеты. Локеры выстраиваются в очередь для получения блокировок, затем выполняются через callback-функцию lockAcquired. До и после действий в пуле вызываются указанные callback-функции хуков. Наконец, PoolManager проверяет состояние.

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

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

Контракт-локер поставляется из официального репозитория или был развернут пользователями. В этих случаях мы можем рассматривать взаимодействия как происходящие через роутер.
Локер и хук интегрированы в один и тот же контракт или контролируются сторонней сущностью. Для этого сценария мы можем рассматривать взаимодействия как происходящие через хук. Таким образом, хук играет двойную роль: локера и обработчика callback-функций.

Модели угроз

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

Модель угрозы I: Хуки доброкачественные, но уязвимые.
Модель угрозы II: Хуки злонамеренные.

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

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

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

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

В широком смысле хуки можно разделить на две категории:

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

Обратите внимание, что хуки, которые не подпадают под эти две категории, не входят в сферу нашего обсуждения.

Несмотря на ограниченный охват, перечислить все возможности здесь невозможно. Поскольку на момент написания этой статьи реальных приложений нет, мы решили изучить репозиторий Awesome Uniswap v4 Hooks для получения некоторых идей.

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

# дефектных проектов	# дефектного контроля доступа	# неправильной проверки входных данных
8	6	2

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

Дефектный контроль доступа

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

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

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

Неправильная проверка входных данных

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

Несмотря на это, остается потенциальный сценарий атаки, а именно небезопасный внешний вызов из-за неправильной проверки входных данных в некоторых уязвимых реализациях хуков:

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

Небезопасный внешний вызов чрезвычайно опасен, так как он может привести к различным типам атак, включая хорошо известные проблемы повторного входа (reentrancy).

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

Смягчение последствий для модели угрозы I

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

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

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

Основываясь на методе доступа к хукам, который определяет потенциальные права, предоставленные хукам, мы можем разделить хуки на две отдельные категории:

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

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

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

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

Автономные хуки

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

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

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

Смягчение последствий для модели угрозы II

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

Заключение

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