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

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

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

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

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

Механизм Uniswap V4

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

1.1 Крючок

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

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

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

  • домодифиепозицион/афтермодифиепозицион

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

  • доПожертвовать/послеПожертвовать

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

Рисунок 1. Процесс Exchange Hook

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

Модель угроз

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

  • Модель угрозы 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 из-за механизма блокировки пользователи должны получить блокировку через контракт, прежде чем выполнять какие-либо операции с пулом средств. Это гарантирует, что контракт, который в данный момент участвует во взаимодействии, является последним контрактом шкафчика.

Тем не менее, существует возможный сценарий атаки, а именно ненадежные внешние вызовы из-за неправильной проверки ввода в некоторых уязвимых реализациях перехватчика:

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

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

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

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

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

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

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

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

Поскольку метод доступа к хуку определяет разрешения, которые могут быть предоставлены хуку, мы делим хук на две категории:

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

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

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

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

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

2.2.2 Независимый крючок

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

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

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

  • С логикой самоуничтожения. Он может быть атакован при совместном вызове selfdestruct и create2.

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

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

в заключение

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

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