Pourquoi dit-on que Hook est une "double tranchant" d'Uniswap V4 ?

Uniswap v4 devrait bientôt faire ses débuts. Cette fois-ci, l'équipe Uniswap a fixé des objectifs ambitieux, prévoyant d'introduire de nouvelles fonctionnalités, notamment un nombre illimité de pools de liquidités pour chaque paire de trading et des frais dynamiques, un design unique, une comptabilité instantanée, des Hooks, ainsi que le support du standard de jetons ERC1155. En exploitant le stockage transitoire, Uniswap v4 devrait être lancé après la mise à niveau de Cancun d'Ethereum.

Parmi les nombreuses innovations, le mécanisme Hook suscite une large attention en raison de son potentiel puissant. Il permet d'exécuter un code spécifique à des moments précis du cycle de vie d'une piscine de liquidité, améliorant considérablement l'évolutivité et la flexibilité de la piscine.

Cependant, le mécanisme Hook peut également être une arme à double tranchant. Bien que puissant et flexible, l'utilisation sécurisée de Hook représente également un défi non négligeable. La complexité de Hook entraîne inévitablement de nouveaux vecteurs d'attaque potentiels. Par conséquent, nous espérons présenter, à travers une série d'articles, une introduction systématique aux problèmes de sécurité et aux risques potentiels associés au mécanisme Hook, afin de promouvoir le développement sécurisé de la communauté. Nous sommes convaincus que ces idées contribueront à construire un Hook sécurisé pour Uniswap v4.

En tant que premier article de cette série, cet article présente les concepts liés au mécanisme Hook dans Uniswap v4 et donne un aperçu des risques de sécurité associés à ce mécanisme.

Mécanisme de Uniswap V4

Avant d'entrer dans les détails, nous devons avoir une compréhension de base du mécanisme de Uniswap v4. Les Hooks, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités importantes pour réaliser des pools de liquidités personnalisés et permettre un routage efficace à travers plusieurs pools.

1.1 Crochet

Hook fait référence à des contrats qui fonctionnent à différentes étapes du cycle de vie d'un pool de liquidité. L'équipe d'Uniswap espère qu'en introduisant Hook, tout le monde pourra prendre des décisions équilibrées. De cette manière, un soutien natif pour des frais dynamiques peut être réalisé, des ordres à cours limité peuvent être ajoutés sur la chaîne, ou des grandes commandes peuvent être dispersées via un market maker à moyenne pondérée par le temps (TWAMM).

Il y a actuellement huit rappels Hook, divisés en quatre groupes (chaque groupe contenant une paire de rappels) :

• avantInitialiser/aprèsInitialiser

• avantModifierPosition/aprèsModifierPosition

• avantÉchange/aprèsÉchange

• avantDonner/aprèsDonner

1.2 Singleton, comptabilité éclair et mécanisme de verrouillage

L'architecture singleton et la comptabilité instantanée visent à améliorer les performances en réduisant les coûts et en garantissant l'efficacité. Elle introduit un nouveau contrat singleton, où toutes les pools de liquidité sont conservées dans le même contrat intelligent. Ce design singleton repose sur un PoolManager pour stocker et gérer l'état de toutes les pools.

Dans les premières versions du protocole Uniswap, des opérations comme l'échange ou l'ajout de liquidité impliquaient un transfert direct de jetons, alors que la version v4 diffère en introduisant la comptabilité instantanée et un mécanisme de verrouillage.

Le fonctionnement du mécanisme de verrouillage est le suivant :

1. Un contrat locker demande un lock sur PoolManager.

2. PoolManager ajoute l'adresse de ce contrat locker à la file lockData et appelle son rappel lockAcquired.

3. Le contrat locker exécute sa logique dans le rappel. Au cours de l'exécution, l'interaction du contrat locker avec le pool peut entraîner un accroissement monétaire non nul. Cependant, à la fin de l'exécution, tous les accroissements doivent être réglés à zéro. De plus, si la file d'attente lockData n'est pas vide, seul le dernier contrat locker peut effectuer des opérations.

4. PoolManager vérifie l'état de la file d'attente lockData et de l'augmentation des devises. Après vérification, PoolManager supprimera le contrat locker.

En résumé, le mécanisme de verrouillage empêche les accès concurrents et garantit que toutes les transactions peuvent être réglées. Le contrat de verrouillage demande un verrou dans l'ordre, puis exécute la transaction via le rappel lockAcquired. Avant et après chaque opération de pool, des rappels Hook correspondants seront déclenchés. Enfin, le PoolManager vérifiera l'état.

Cette méthode signifie que l'ajustement des opérations concerne le solde net interne, plutôt que d'effectuer un transfert instantané. Toute modification sera enregistrée dans le solde interne du pool, tandis que le transfert réel aura lieu à la fin de l'opération. Ce processus garantit qu'il n'y a pas de jetons non réglés, maintenant ainsi l'intégrité des fonds.

En raison de l'existence du mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Au contraire, toute interaction doit passer par un contrat. Ce contrat agit comme un locker intermédiaire et nécessite une demande de verrouillage avant d'effectuer toute opération de pool.

Il existe principalement deux scénarios d'interaction de contrats :

• Un contrat locker provient du code source officiel ou est déployé par un utilisateur. Dans ce cas, nous pouvons considérer l'interaction comme passant par un routeur.

• Un contrat locker est intégré dans le même contrat que Hook, ou contrôlé par une entité tierce. Dans ce cas, nous pouvons considérer l'interaction comme se faisant via Hook. Dans ce cas, Hook joue à la fois le rôle du contrat locker et est responsable du traitement des rappels.

Modèle de menace

Avant de discuter des problèmes de sécurité connexes, nous devons définir le modèle de menace. Nous considérons principalement les deux situations suivantes :

• Modèle de menace I : Hook lui-même est bénin, mais présente des vulnérabilités.

• Modèle de menace II : Le Hook lui-même est malveillant.

Dans la partie suivante, nous discuterons des problèmes de sécurité potentiels en fonction de ces deux modèles de menace.

2.1 Problèmes de sécurité dans le modèle de menace I

Le modèle de menace I se concentre sur les vulnérabilités liées au Hook lui-même. Ce modèle de menace suppose que les développeurs et leur Hook ne sont pas malveillants. Cependant, les vulnérabilités connues existantes des contrats intelligents peuvent également apparaître dans le Hook. Par exemple, si le Hook est mis en œuvre en tant que contrat évolutif, il peut rencontrer des problèmes similaires à ceux liés à la vulnérabilité UUPSUpgradeable d'OpenZeppelin.

Étant donné les facteurs ci-dessus, nous choisissons de nous concentrer sur les vulnérabilités potentielles spécifiques à la version v4. Dans Uniswap v4, un Hook est un contrat intelligent capable d'exécuter une logique personnalisée avant ou après les opérations de pool central (y compris l'initialisation, la modification de position, l'échange et la collecte). Bien que l'on s'attende à ce que le Hook implémente une interface standard, il permet également d'inclure une logique personnalisée. Par conséquent, notre discussion sera limitée à la logique impliquant l'interface standard des Hook. Ensuite, nous allons essayer d'identifier les sources potentielles de vulnérabilités, par exemple, comment un Hook pourrait abuser de ces fonctions standard de Hook.

Plus précisément, nous allons nous concentrer sur les deux types de Hook suivants :

• Le premier type de hook, garde des fonds des utilisateurs. Dans ce cas, un attaquant pourrait cibler ce hook pour transférer des fonds, entraînant une perte d'actifs.

• Deuxième type de hook, stocke les données d'état critiques sur lesquelles les utilisateurs ou d'autres protocoles dépendent. Dans ce cas, un attaquant pourrait essayer de modifier l'état critique. Lorsque d'autres utilisateurs ou protocoles utilisent un état incorrect, cela peut présenter des risques potentiels.

Veuillez noter que les hooks en dehors de ces deux plages ne font pas partie de notre discussion.

Dans l'ensemble, nous avons identifié 22 projets pertinents (en excluant les projets non liés à Uniswap v4). Parmi ces projets, nous pensons que 8 (36 %) présentent des vulnérabilités. Parmi ces 8 projets vulnérables, 6 présentent des problèmes de contrôle d'accès et 2 sont susceptibles d'être affectés par des appels externes non fiables.

2.1.1 Problèmes de contrôle d'accès

Dans cette partie de la discussion, nous nous concentrons principalement sur les problèmes potentiels liés aux fonctions de rappel dans v4, y compris 8 rappels hook et les rappels de verrouillage. Bien sûr, il y a d'autres cas à vérifier, mais ceux-ci varient en fonction de la conception et ne sont pas dans le champ de notre discussion.

Ces fonctions ne devraient être appelées que par le PoolManager et non par d'autres adresses (y compris les EOA et les contrats). Par exemple, dans le cas où les récompenses sont distribuées par la clé du fonds de pool, si la fonction correspondante peut être appelée par n'importe quel compte, les récompenses pourraient être perçues par erreur.

Ainsi, pour les hooks, il est crucial d'établir un mécanisme de contrôle d'accès solide, surtout s'ils peuvent être appelés par d'autres parties en dehors de la piscine elle-même. En gérant strictement les droits d'accès, les pools de liquidités peuvent réduire considérablement les risques d'interactions non autorisées ou malveillantes avec les hooks.

2.1.2 Problèmes de validation des entrées

Dans Uniswap v4, en raison du mécanisme de verrouillage, les utilisateurs doivent obtenir un lock via le contrat avant d'effectuer toute opération de pool de liquidités. Cela garantit que le contrat actuellement participant à l'interaction est le dernier contrat de verrouillage.

Néanmoins, il existe un scénario d'attaque possible, à savoir des appels externes non fiables résultant d'une validation des entrées inappropriée dans certaines implémentations de Hook vulnérables :

• Tout d'abord, le hook n'a pas vérifié le pool de fonds avec lequel l'utilisateur souhaite interagir. Il pourrait s'agir d'un pool de fonds malveillant contenant des jetons frauduleux et exécutant une logique nuisible.

• Deuxièmement, certaines fonctions hook clés permettent des appels externes arbitraires.

Les appels externes non fiables sont extrêmement dangereux, car ils peuvent entraîner divers types d'attaques, y compris l'attaque par réentrance que nous connaissons bien.

Pour attaquer ces hooks vulnérables, un attaquant peut enregistrer un pool de fonds malveillant pour ses tokens fictifs, puis appeler le hook pour exécuter des opérations dans le pool de fonds. Lors de l'interaction avec le pool de fonds, la logique du token malveillant détourne le flux de contrôle afin de mener des actions malveillantes.

2.1.3 Mesures de protection contre le modèle de menace I

Pour éviter de tels problèmes de sécurité liés aux hooks, il est crucial de valider les interactions en mettant en œuvre un contrôle d'accès nécessaire sur les fonctions externes/publiques sensibles et en validant les paramètres d'entrée. De plus, la protection contre les réentrées peut aider à garantir que les hooks ne soient pas exécutés plusieurs fois dans le flux logique standard. En mettant en œuvre des mesures de sécurité appropriées, le fonds peut réduire les risques associés à de telles menaces.

2.2 Problèmes de sécurité dans le modèle de menace II

Dans ce modèle de menace, nous supposons que le développeur et son hook sont malveillants. Étant donné l'étendue des implications, nous ne nous concentrons que sur les problèmes de sécurité liés à la version v4. Ainsi, la clé réside dans la capacité du hook fourni à gérer les actifs cryptographiques lors des transferts ou des autorisations des utilisateurs.

Puisque la méthode d'accès au hook détermine les autorisations qui peuvent être accordées au hook, nous classons les hooks en deux catégories :

• Hook de type géré : le hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec le hook via un routeur (qui peut être fourni par Uniswap).

• Hook autonome : le hook est un point d'entrée qui permet aux utilisateurs d'interagir directement avec lui.

2.2.1 Hook de type custodial

Dans ce cas, les actifs cryptographiques de l'utilisateur (y compris les jetons natifs et d'autres jetons) sont transférés ou autorisés au routeur. Comme le PoolManager effectue une vérification des soldes, il est difficile pour un hook malveillant de voler directement ces actifs. Cependant, il existe encore un potentiel d'attaque. Par exemple, le mécanisme de gestion des frais de la version v4 pourrait être manipulé par un attaquant via un hook.

2.2.2 Hook indépendant

Lorsque le Hook est utilisé comme point d'entrée, la situation devient plus complexe. Dans ce cas, puisque les utilisateurs peuvent interagir directement avec le hook, celui-ci obtient plus de pouvoir. En théorie, le hook peut exécuter n'importe quelle opération souhaitée via cette interaction.

Dans la version v4, la validation de la logique du code est très critique. Le principal problème réside dans la possibilité de manipuler la logique du code. Si le hook est évolutif, cela signifie qu'un hook apparemment sécurisé peut devenir malveillant après une mise à niveau, ce qui constitue un risque majeur. Ces risques incluent :

• Agents évolutifs (qui peuvent être attaqués directement) ;

• Logique d'auto-destruction. Peut être attaqué dans le cas d'un appel conjoint à selfdestruct et create2.

2.2.3 Mesures de prévention contre le modèle de menace II

Un point crucial est d'évaluer si le hook est malveillant. Plus précisément, pour les hooks gérés, nous devrions nous concentrer sur le comportement de gestion des frais ; alors que pour les hooks indépendants, le principal point d'attention est de savoir s'ils sont évolutifs.

Conclusion

Dans cet article, nous présentons d'abord un aperçu des mécanismes clés liés aux problèmes de sécurité des Hooks dans Uniswap v4. Ensuite, nous proposons deux modèles de menace et résumons les risques de sécurité associés.

Dans les articles suivants, nous examinerons chaque modèle de menace.