O Uniswap v4 está a caminho! A equipe tem planos ambiciosos para introduzir uma série de novos recursos[1], incluindo (teoricamente) um número ilimitado de pools e taxas dinâmicas para cada par de negociação, singleton, flash accounting, hooks e suporte a ERC1155. Aproveitando o armazenamento transiente introduzido pelo EIP-1153, espera-se que o Uniswap v4 seja lançado após a atualização Cancun do Ethereum.
Entre essas inovações, o mecanismo de hook tem atraído atenção significativa devido ao seu poderoso potencial. Ele permite a execução de código específico em pontos particulares durante a operação de um pool, aumentando consideravelmente a extensibilidade e a flexibilidade dos pools.
No entanto, o mecanismo de hook também pode ser uma faca de dois gumes. Embora seja poderoso e flexível, o desafio de utilizá-lo com segurança não pode ser ignorado. Essa complexidade inevitavelmente abre novos vetores de ataque potenciais. Com o objetivo de contribuir para a comunidade sob uma perspectiva de segurança, nossa meta é apresentar uma série de artigos que examinam as questões e preocupações de segurança relacionadas a esse mecanismo de forma sistemática. Acreditamos que essas percepções ajudarão a iluminar a construção de hooks seguros para o Uniswap v4.
Este artigo é o primeiro desta série, oferecendo uma visão geral abrangente e uma compreensão fundamental para nossos leitores. Fique atento para mais discussões esclarecedoras!
O Mecanismo do Uniswap v4
Antes de nos aprofundarmos nos detalhes, precisamos ter uma compreensão básica do mecanismo do Uniswap v4. De acordo com o anúncio oficial[1] e o whitepaper[2], hooks, a arquitetura singleton e o flash accounting são três recursos-chave que permitem a personalização de pools e o roteamento eficiente entre muitos pools.
Hooks
Os hooks na v4 são projetados para permitir que qualquer pessoa tome decisões de troca por meio de hooks, que são contratos executados em vários pontos do ciclo de vida de uma ação de pool. Ao fazer isso, é possível personalizar pools que suportam nativamente taxas dinâmicas, adicionar ordens limitadas on-chain ou atuar como um formador de mercado de média ponderada pelo tempo (TWAMM) para distribuir grandes ordens ao longo do tempo.
Atualmente, existem oito callbacks de hook, organizados em quatro grupos (cada grupo contém um par de callbacks):
- beforeInitialize/afterInitialize
- beforeModifyPosition/afterModifyPosition
- beforeSwap/afterSwap
- beforeDonate/afterDonate
A seguir, é mostrado o fluxo dos hooks de swap fornecido pelo whitepaper[2].
A equipe do Uniswap forneceu alguns exemplos (por exemplo, o TWAMM Hook[3]) para demonstrar o uso, e os participantes da comunidade também contribuem. A documentação oficial[4] aponta para o repositório Awesome Uniswap v4 Hooks[5], que reúne mais exemplos de hooks.
Singleton, Flash Accounting e Mecanismo de Lock
A arquitetura singleton e o flash accounting são projetados para melhorar o desempenho, reduzindo custos e garantindo eficiência. Especificamente, é introduzido um novo contrato singleton, onde todos os pools residem em um único contrato inteligente. Esse design singleton depende de um PoolManager para armazenar e gerenciar todos os estados de todos os pools.
Diferindo das versões anteriores do Protocolo Uniswap, onde operações como swap ou adição de liquidez envolviam transferências diretas de tokens, o Uniswap v4 introduz o flash accounting junto com um mecanismo de lock.
Especificamente, o mecanismo de lock opera da seguinte maneira:
- Um contrato locker solicita um lock no
PoolManager. - O
PoolManageradiciona o endereço do locker à fila lockData e invoca seu callbacklockAcquired. - O locker executa sua lógica no callback. Durante a execução de um locker, suas interações com pools podem resultar em deltas de moeda não nulos. No entanto, ao final da execução, todos os deltas devem ser liquidados a zero. Além disso, se a fila lockData não estiver vazia, apenas o último locker pode realizar operações.
- Em seguida, o
PoolManagerverifica o estado da fila lockData e os deltas de moeda. Após a verificação, oPoolManagerremoverá o locker.
Em resumo, o mecanismo de lock previne o acesso concorrente e garante a liquidação. Os lockers fazem fila para obter locks e então executam via callback lockAcquired. Antes e depois das ações do pool, os callbacks de hook especificados são invocados. Por fim, o PoolManager verifica o estado.
Essa abordagem significa que as operações ajustam um saldo líquido interno (ou seja, delta), em vez de executar transferências imediatas. Quaisquer modificações são registradas no saldo interno do pool, com as transferências reais ocorrendo ao final da operação (ou seja, lock). Esse processo garante que não haja tokens pendentes, preservando assim a solvência.
Devido ao mecanismo de lock, uma EOA (Conta de Propriedade Externa) não pode interagir diretamente com o PoolManager. Em vez disso, qualquer interação deve passar por um contrato. O contrato funciona como um locker intermediário para solicitar um lock antes de qualquer ação no pool.
Existem principalmente dois cenários de interação com contratos:
-
O contrato locker vem do repositório oficial ou foi implantado por usuários. Nesses casos, podemos ver as interações como sendo feitas por meio de um router.
-
O locker e o hook são integrados no mesmo contrato ou controlados por uma entidade terceira. Para esse cenário, podemos ver as interações como sendo feitas por meio de um hook. Portanto, o hook desempenha o papel duplo de locker e manipulador de callback.
Modelos de Ameaça
Os modelos de ameaça precisam ser determinados antes de discutir as questões de segurança correspondentes. Basicamente, existem certas considerações que surgem ao usar hooks:
- Modelo de ameaça I: Os hooks são benignos, mas vulneráveis.
- Modelo de ameaça II: Os hooks são maliciosos.
Nas seções seguintes, discutiremos possíveis problemas/preocupações de segurança com base nos modelos de ameaça.
Preocupações de Segurança no Modelo de Ameaça I
O modelo de ameaça I foca em vulnerabilidades relacionadas aos próprios hooks. Obviamente, esse modelo de ameaça assume que os desenvolvedores e seus hooks são benignos. No entanto, vulnerabilidades conhecidas de contratos inteligentes também podem ocorrer nos hooks. Por exemplo, se o hook for implementado como um contrato atualizável, ele pode sofrer com algumas vulnerabilidades semelhantes à vulnerabilidade UUPSUpgradeable da biblioteca da OZ[6].
Tendo isso em mente, optamos por nos concentrar em vulnerabilidades potenciais específicas da v4. Especificamente, no Uniswap v4, hooks são contratos inteligentes personalizáveis capazes de executar lógica antes ou depois das ações principais do pool (incluindo initialize, modifyPosition, swap e donate). Espera-se que os hooks implementem a interface padrão de hook, mas também têm permissão para incorporar lógica personalizada. Portanto, nosso escopo está limitado à lógica associada à interface padrão de hook. Podemos então resumir como os hooks provavelmente empregam essas funções padrão de hook para identificar possíveis fontes de vulnerabilidades.
De forma geral, os hooks podem se enquadrar em duas categorias:
- Hooks atuando como custodiantes de fundos de usuários. Nesses casos, os atacantes podem mirar no hook para transferir fundos, levando a perdas de ativos.
- Hooks armazenando dados de estado críticos dos quais usuários ou outros protocolos dependem. Para esses hooks, os atacantes podem deliberadamente alterar estados críticos. Os estados incorretos, quando usados por outros usuários ou protocolos, introduzem riscos potenciais.
Observe que hooks que não se enquadram nessas duas categorias estão fora do escopo de nossa discussão.
Apesar do escopo limitado, ainda não é viável enumerar todas as possibilidades aqui. Como não há aplicações reais no momento desta escrita, decidimos examinar o repositório Awesome Uniswap v4 Hooks em busca de insights.
Após examinar minuciosamente o repositório (com hash de commit 3a0a444922f26605ec27a41929f3ced924af6075), identificamos várias vulnerabilidades críticas. Estas derivam principalmente das interações arriscadas entre hooks, PoolManager e terceiros externos. As vulnerabilidades se enquadram em duas categorias principais: controle de acesso falho e validação de entrada inadequada. Os resultados estão resumidos na tabela abaixo:
| # de projetos com falhas | # de controle de acesso falho | # de validação de entrada inadequada |
|---|---|---|
| 8 | 6 | 2 |
No geral, identificamos 22 projetos pertinentes (excluindo alguns que pareciam não relacionados ao Uniswap v4). Destes, 8 (ou 36%) foram considerados vulneráveis. Especificamente, controle de acesso falho foi detectado em 6 desses projetos vulneráveis, enquanto 2 eram suscetíveis a chamadas externas não confiáveis.
Controle de Acesso Falho
Nesta discussão, focamos nos problemas de controle de acesso relacionados à v4 que derivam das funções de callback da v4, que incluem 8 callbacks de hook e o callback de lock. É claro que outros casos também podem precisar ser verificados. No entanto, esses casos dependem do design, o que está além do escopo especificado em nossa discussão anterior.
Essas funções devem ser invocadas apenas pelo PoolManager, e não por outros endereços (incluindo EOAs e contratos). Por exemplo, considere uma situação em que uma recompensa é distribuída pela chave do pool. Se a função correspondente puder ser invocada por contas arbitrárias, a recompensa poderia ser reivindicada incorretamente.
Dado isso, é crucial estabelecer mecanismos robustos de controle de acesso para hooks, especialmente porque eles podem ser invocados por partes que não sejam o próprio pool. Por meio de um gerenciamento cuidadoso das permissões de acesso, os pools podem minimizar substancialmente o risco de interações não autorizadas ou maliciosas com os hooks.
Validação de Entrada Inadequada
No Uniswap v4, devido ao mecanismo de lock, os usuários devem obter um lock por meio de um contrato antes de executar qualquer ação no pool. Isso garante que o contrato atualmente em interação seja o último locker.
Apesar disso, ainda existe um cenário de ataque potencial, ou seja, chamada externa não confiável devido à validação de entrada inadequada em algumas implementações de hook vulneráveis:
- Primeiro, o hook não valida o pool com o qual os usuários pretendem interagir. Isso poderia ser um pool malicioso carregando tokens falsos e executando lógica prejudicial.
- Segundo, algumas funções críticas de hook permitem invocações externas arbitrárias.
A chamada externa não confiável é extremamente perigosa porque pode levar a vários tipos de ataques, incluindo os conhecidos problemas de reentrância.
Para explorar hooks vulneráveis, um atacante poderia registrar um pool malicioso para seus tokens falsos e, em seguida, invocar o hook para executar ações no pool. Ao interagir com o pool, a lógica do token malicioso sequestra o fluxo de controle para facilitar comportamentos inadequados.
Mitigação para o Modelo de Ameaça I
Para evitar tais problemas com hooks, é essencial validar as interações aplicando adequadamente o controle de acesso necessário para funções externas/públicas sensíveis e a verificação dos argumentos de entrada. Além disso, um guard de reentrância pode ser útil para garantir que o hook não possa ser executado repetidamente dentro do fluxo de lógica padrão. Ao implementar salvaguardas adequadas, os pools podem mitigar os riscos associados a esse tipo de ameaça.
Preocupações de Segurança no Modelo de Ameaça II
Neste modelo de ameaça, os desenvolvedores e seus hooks são considerados maliciosos. Dada a ampla gama de possibilidades, optamos por focar principalmente nas questões relacionadas à v4. Consequentemente, a principal consideração é se os hooks fornecidos são capazes de lidar com os ativos criptográficos que os usuários transferiram ou aprovaram.
Com base no método de acesso aos hooks, que determina as permissões potenciais concedidas a eles, podemos classificar os hooks em duas categorias distintas:
- Hooks Gerenciados: Os hooks não são o ponto de entrada. Os usuários devem interagir com os hooks por meio de um router, provavelmente fornecido pelo Uniswap.
- Hooks Independentes: Os hooks são o ponto de entrada, permitindo que os usuários interajam diretamente com eles.
Hooks Gerenciados
No caso de Hooks Gerenciados, os ativos criptográficos dos usuários (incluindo tokens nativos e outros) são transferidos ou aprovados para o router. Devido à verificação de saldo imposta pelo PoolManager, não é simples para hooks maliciosos colher diretamente esses ativos.
No entanto, superfícies de ataque potenciais ainda existem. Por exemplo, o mecanismo de gerenciamento de taxas na v4 poderia potencialmente ser manipulado por atacantes por meio de hooks.
Hooks Independentes
A situação se torna mais complexa quando os hooks são usados como ponto de entrada na forma de Hooks Independentes. Nesse cenário, os hooks ganham mais poder, pois os usuários podem interagir diretamente com eles. Teoricamente, os hooks podem realizar qualquer ação que desejarem por meio dessa interação.
No cenário da v4, a validação da lógica do código é um ponto crítico. A principal preocupação é se a lógica do código pode ser manipulada. Os hooks podem ser implementados como atualizáveis, o que significa que um hook que parece seguro poderia potencialmente ser atualizado para um malicioso posteriormente, representando um risco significativo. Isso inclui:
- Proxies atualizáveis, que podem ser explorados diretamente;
- Equipados com lógica de autodestruição, que pode ser explorada devido ao uso combinado de
selfdestructecreate2.
Mitigação para o Modelo de Ameaça II
É essencial avaliar se os hooks são maliciosos. Especificamente, para hooks gerenciados, devemos nos concentrar no comportamento do gerenciamento de taxas; enquanto para hooks independentes, a principal preocupação é se eles são ou não atualizáveis.
Conclusão
Neste artigo, inicialmente fornecemos um breve resumo dos mecanismos centrais do Uniswap v4 que se relacionam com as questões de segurança dos hooks da v4. Em seguida, definimos dois modelos de ameaça e oferecemos uma discussão de alto nível sobre suas respectivas questões de segurança. Nos próximos artigos desta série, forneceremos análises detalhadas dessas questões de segurança em cada modelo de ameaça. Fique atento!
Referências
[1] Nossa Visão para o Uniswap V4
[2] Rascunho do whitepaper do Uniswap v4
[4] Exemplos de Hook
[6] Post-mortem da Vulnerabilidade UUPSUpgradeable
