Поверьте или нет, Uniswap v4 скоро встретит всех!

На этот раз команда Uniswap поставила перед собой амбициозные цели и планирует внедрить множество новых функций, включая неограниченное количество пулов ликвидности и динамические комиссии для каждой торговой пары, одноэлементный дизайн, флэш-учет, Hook и поддержку стандарта токенов ERC1155. Ожидается, что Uniswap v4, использующий временное хранилище, представленное EIP-1153, будет выпущен после обновления Ethereum Cancun. Среди множества нововведений механизм Hook привлек широкое внимание благодаря своему мощному потенциалу. Механизм Hook позволяет выполнять определенный код в определенных точках жизненного цикла пула ликвидности, значительно повышая масштабируемость и гибкость пулов. Однако механизм «Крюк» может быть и палкой о двух концах. Несмотря на то, что он мощный и гибкий, безопасное использование Hook также является серьезной проблемой. Сложность Hook неизбежно порождает новые потенциальные векторы атак. Поэтому мы надеемся написать серию статей, чтобы систематически знакомить с проблемами безопасности и потенциальными рисками, связанными с механизмом Hook, чтобы способствовать развитию безопасности сообщества. Мы считаем, что эти идеи помогут создать безопасные хуки Uniswap v4. Как первая статья этой серии, эта статья знакомит с концепциями, связанными с механизмом Hook в Uniswap v4, и описывает риски безопасности, связанные с механизмом Hook.

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

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

1.1 Хук

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

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

Ниже приведен поток обмена Hook, представленный в белой книге [2].

Рисунок 1: Поток Swap Hook

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

1.2 Одиночка, мгновенное учет и механизм блокировки

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

👇🏻 Механизм блокировки работает следующим образом: 1. Контракт замка запрашивает блокировку у PoolManager. 2. PoolManager добавляет адрес контракта замка в очередь lockData и вызывает его обратный вызов lockAcquired. 3. Контракт замка выполняет свою логику в обратном вызове. Взаимодействия с пулом во время выполнения могут привести к увеличению валюты, отличной от нуля. Однако к концу выполнения все увеличения должны быть равны нулю. Кроме того, если очередь lockData не пуста, операции могут выполняться только последним контрактом замка. 4. PoolManager проверяет состояние очереди lockData и увеличения валюты. После проверки PoolManager удаляет контракт замка.

В заключение, механизм блокировки предотвращает одновременный доступ и обеспечивает возможность проведения всех транзакций. Контракты Locker запрашивают блокировки последовательно, затем выполняют сделки через обратный вызов lockAcquired. Соответствующие обратные вызовы Hook срабатывают до и после каждой операции с пулом. Наконец, PoolManager проверяет состояния. Это означает, что операции корректируют внутренние балансы нетто (т.е. дельту), а не выполняют мгновенные переводы. Любые изменения регистрируются во внутренних балансах пула, а фактические переводы происходят при завершении операции (т.е. блокировки). Этот процесс гарантирует отсутствие невыполненных токенов, обеспечивая целостность средств. Из-за механизма блокировки внешние управляемые счета (EOA) не могут взаимодействовать напрямую с PoolManager. Вместо этого любое взаимодействие должно проходить через контракт. Этот контракт действует как посредник-блокировщик, запрашивая блокировку перед проведением любых операций с пулом. (12/08)

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

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

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

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

• Модель угроз I: Сам крюк безобиден, но содержит уязвимости.
• Модель угроз II: Сам крюк злонамеренный.

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

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

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

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

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

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

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

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

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

2.1.2 Проблемы валидации ввода

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

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

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

2.1.3 Противодействие Модели Угроз I

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

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

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

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

Рисунок 2: Пример зловредного хука

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

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

2.2.2 Автономные крючки

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

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

2.2.3 Противодействие угрозам модели II

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

- 3 - Заключение

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

Ссылки

[1] Наше видение Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Черновик белой книги Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Uniswap v4 TWAMM Hook
https://blog.uniswap.org/v4-twamm-hook

[4] Примеры Hook
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Удивительные крючки Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] UUPSUpgradeable Уязвимость Пост-мортем
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

О компании BlockSec BlockSec — ведущая мировая компания по обеспечению безопасности блокчейна, основанная в 2021 году известными экспертами в области безопасности. Компания стремится повысить безопасность и удобство использования в мире Web3, чтобы способствовать широкому внедрению Web3. Для достижения этой цели BlockSec предоставляет услуги аудита безопасности смарт-контрактов и цепочек EVM, систему разработки, тестирования и перехвата хакеров под названием Phalcon для владельцев проектов, платформу для отслеживания и расследования фондов под названием MetaSleuth, а также плагины эффективности для разработчиков web3 под названием MetaDock. В настоящее время компания обслужила более 300 клиентов, включая такие известные проекты, как MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, и получила два раунда финансирования на общую сумму более десятков миллионов долларов от инвестиционных институтов, таких как Oasis Capital, IDG Capital и Distributed Capital. Домашняя страница:www.blocksec.com

Twitter：https://twitter.com/БлокSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Disclaimer：

1. Эта статья перепечатана из [БлокSec]. Все авторские права принадлежат оригинальному автору [БлокSec]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Гейт Учитсякоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.