Почему говорят, что Hook — это "двусторонний меч" Uniswap V4?

Uniswap v4 ожидается в ближайшем будущем. На этот раз команда Uniswap поставила перед собой амбициозные цели, планируя внедрить множество новых функций, включая поддержку неограниченного количества ликвидных пулов и динамических сборов для каждой торговой пары, единый дизайн, молниеносный учет, Hook и поддержку стандарта токенов ERC1155. Используя временное хранилище, Uniswap v4 планируется выпустить после обновления Ethereum Cancun.

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

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

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

Механизм Uniswap V4

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

1.1 Крючок

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

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

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

• передИзменениемПозиции/послеИзмененияПозиции

• передОбменом/послеОбмена

• передПожертвованием/послеПожертвования

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

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

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

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

1. Некоторый контракт locker запрашивает блокировку на PoolManager.

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

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

4. PoolManager проверяет состояние очереди lockData и прироста валюты. После проверки PoolManager удалит этот контракт locker.

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

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

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

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

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

• Некоторый контракт locker интегрирован с Hook в одном и том же контракте или контролируется третьей стороной. В этом случае мы можем рассматривать взаимодействие как осуществляемое через Hook. В этом случае Hook выполняет роль контракта locker и отвечает за обработку обратного вызова.

Модель угроз

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

• Модель угроз I: Hook сам по себе является благожелательным, но содержит уязвимости.

• Модель угроз II: Hook сам по себе является злонамеренным.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2 Проблемы с верификацией ввода

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

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

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

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

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

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

2.1.3 Меры по предотвращению угроз модели I

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

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

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

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

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

• Независимый Hook: hook является точкой входа, позволяющей пользователям взаимодействовать с ним напрямую.

2.2.1 Хранение Hook

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

2.2.2 Независимый Hook

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

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

• Обновляемый прокси (может быть непосредственно атакован);

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

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

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

Вывод

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

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