Croyez-le ou non, Uniswap v4 va bientôt rencontrer tout le monde !

Cette fois, l'équipe Uniswap s'est fixé des objectifs ambitieux et prévoit d'introduire de nombreuses nouvelles fonctionnalités, y compris un nombre illimité de pools de liquidité et des frais dynamiques pour chaque paire de trading, un design singleton, une comptabilité flash, Hook et le support du standard de jeton ERC1155. En utilisant le stockage transitoire introduit par l'EIP-1153, Uniswap v4 devrait être publié après la mise à niveau d'Ethereum Cancun. Parmi les nombreuses innovations, le mécanisme Hook a attiré une large attention en raison de son potentiel puissant. Le mécanisme Hook permet d'exécuter un code spécifique à des points spécifiques du cycle de vie d'un pool de liquidités, améliorant considérablement la scalabilité et la flexibilité des pools. Cependant, le mécanisme Hook peut aussi être une arme à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sûre de Hook est également un défi significatif. La complexité de Hook apporte inévitablement de nouveaux vecteurs d'attaque potentiels. Par conséquent, nous espérons rédiger une série d'articles pour introduire systématiquement les problèmes de sécurité et les risques potentiels liés au mécanisme Hook, afin de promouvoir le développement sécurisé de la communauté. Nous pensons que ces perspectives aideront à construire des Hooks Uniswap v4 sécurisés. En tant qu'article d'ouverture de cette série, cet article présente les concepts liés au mécanisme Hook dans Uniswap v4 et expose les risques de sécurité associés au mécanisme Hook.

- 1 - Mécanisme de Uniswap V4

Avant de plonger plus en profondeur, nous avons besoin d'une compréhension de base des mécanismes derrière Uniswap v4. Selon l'annonce officielle [1] et le livre blanc [2], les Hooks, l'architecture singleton et la comptabilité flash sont trois fonctionnalités importantes qui permettent des pools de liquidités personnalisées et un routage efficace à travers plusieurs pools.

1.1 Crochet

Les crochets font référence à des contrats qui s'exécutent à différentes étapes du cycle de vie d'un pool de liquidités. L'équipe d'Uniswap espère permettre à quiconque de prendre des décisions en introduisant des crochets. De cette façon, le support natif pour les frais dynamiques, les ordres limites sur chaîne ou les fournisseurs de liquidité moyens pondérés dans le temps (TWAMMs) pour diviser de gros ordres peut être mis en œuvre. Actuellement, il existe huit crochets de rappel, divisés en quatre paires (chaque paire contient un rappel avant et un rappel après)

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• avantSwap/aprèsSwap
• beforeDonate/afterDonate

Ci-dessous se trouve le flux du swap Hook introduit dans le livre blanc [2].

Figure 1: Flux de Swap Hook

L'équipe Uniswap a démontré la méthodologie avec quelques exemples (par exemple le Hook TWAMM [3]), et les participants de la communauté ont également apporté leur contribution. La documentation officielle [4] renvoie également au dépôt Awesome Uniswap v4 Hooks [5], qui recueille plus d'exemples de Hooks.

1.2 Singleton, Comptabilité Flash et Mécanisme de Verrouillage

L'architecture singleton et la comptabilité flash visent à améliorer les performances en réduisant les coûts et en garantissant l'efficacité. Il introduit un nouveau contrat singleton où tous les pools de liquidités sont stockés dans le même contrat intelligent. Cette conception singleton repose sur un PoolManager pour stocker et gérer l'état de tous les pools. Dans les premières versions du protocole Uniswap, des opérations telles que l'échange ou l'ajout de liquidité impliquaient des transferts de jetons directs. La version 4 est différente en ce sens qu'elle introduit la comptabilité flash et un mécanisme de verrouillage.

👇🏻 Le mécanisme de verrouillage fonctionne comme suit : 1. Un contrat de casier demande un verrouillage au PoolManager. 2. Le PoolManager ajoute l'adresse du contrat de casier à la file d'attente lockData et appelle son rappel lockAcquired. 3. Le contrat de casier exécute sa logique dans le rappel. Les interactions avec le pool pendant l'exécution peuvent entraîner des incréments de devises non nuls. Cependant, à la fin de l'exécution, tous les incréments doivent être nuls. De plus, si la file d'attente lockData n'est pas vide, seul le dernier contrat de casier peut exécuter des opérations. 4. Le PoolManager vérifie l'état de la file d'attente lockData et des incréments de devises. Après vérification, le PoolManager retire le contrat de casier.

En résumé, le mécanisme de verrouillage empêche l'accès concurrentiel et garantit que toutes les transactions peuvent être réglées. Les contrats de verrouillage demandent des verrous séquentiellement, puis exécutent des transactions via le rappel lockAcquired. Les rappels Hook correspondants sont déclenchés avant et après chaque opération de pool. Enfin, le PoolManager vérifie les états. Cela signifie que les opérations ajustent les soldes nets internes (c'est-à-dire le delta) plutôt que d'effectuer des transferts instantanés. Toutes les modifications sont enregistrées dans les soldes internes du pool, les transferts réels ayant lieu lorsque l'opération (c'est-à-dire le verrouillage) se termine. Ce processus garantit qu'il n'y a pas de jetons en attente, maintenant l'intégrité des fonds. En raison du mécanisme de verrouillage, les comptes appartenant à des tiers (EOAs) ne peuvent pas interagir directement avec le PoolManager. Au lieu de cela, toute interaction doit passer par un contrat. Ce contrat agit comme un verrou intermédiaire, demandant un verrou avant d'effectuer des opérations de pool.

👇🏻 Il existe deux principaux scénarios d'interaction de contrat :

• Un contrat de verrouillage provient de la base de code officielle, ou est déployé par un utilisateur. Dans ce cas, nous pouvons considérer l'interaction comme passant par un routeur.
• Un contrat de casier et un Hook sont intégrés dans le même contrat, ou contrôlés par une entité tierce. Dans ce cas, nous pouvons considérer l'interaction comme passant par un Hook. Ici, le Hook joue le rôle à la fois du contrat de casier et de la gestion des rappels.

- 2 -Modèle de Menace

Avant de discuter des problèmes de sécurité connexes, nous devons établir le modèle de menace. Nous considérons principalement les deux cas suivants :

• Modèle de menace I : Le Hook lui-même est bénin mais contient des vulnérabilités.
• Modèle de menace II : Le Hook lui-même est malveillant.

Dans les sections suivantes, nous discuterons des problèmes de sécurité potentiels selon 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 associées au crochet lui-même. Ce modèle de menace suppose que le développeur et son Hook ne sont pas malveillants. Cependant, des vulnérabilités connues existantes dans les contrats intelligents peuvent également apparaître dans les Hooks. Par exemple, si un Hook est implémenté en tant que contrat évolutif, il peut rencontrer des problèmes liés à des vulnérabilités telles que celle d’OpenZeppelin UUPSUpgradeable. Compte tenu des facteurs ci-dessus, nous avons choisi de nous concentrer sur les vulnérabilités potentielles propres à la version 4. Dans Uniswap v4, les hooks sont des contrats intelligents qui peuvent exécuter une logique personnalisée avant ou après les opérations du pool de cœurs (y compris l’initialisation, la modification de position, l’échange et la collecte). Bien que les hooks soient censés implémenter une interface standard, ils permettent également une logique personnalisée. Par conséquent, notre discussion se limitera à la logique impliquant les interfaces Hook standard. Nous essaierons ensuite d’identifier les sources potentielles de vulnérabilités, par exemple comment les Hooks pourraient abuser de ces fonctions standard des Hooks.

👇🏻 Plus précisément, nous nous concentrerons sur les deux types de crochets suivants :

• Le premier type de crochet retient les fonds de l'utilisateur. Dans ce cas, un attaquant pourrait attaquer ce crochet pour transférer des fonds, causant une perte d'actifs.
• Le deuxième type de crochet stocke des données d'état critique sur lesquelles les utilisateurs ou d'autres protocoles s'appuient. Dans ce cas, un attaquant pourrait essayer de modifier l'état critique. Lorsque d'autres utilisateurs ou protocoles utilisent l'état incorrect, il peut y avoir des risques potentiels.

Notez que les hooks en dehors de ces deux domaines ne sont pas discutés ici. Étant donné qu'il n'y a pas de cas d'utilisation réels des Hooks à l'époque de la rédaction de cet article, nous allons prendre quelques informations du dépôt Awesome Uniswap v4 Hooks. Après une étude approfondie du dépôt Awesome Uniswap v4 Hooks (commit hash 3a0a444922f26605ec27a41929f3ced924af6075), nous avons identifié plusieurs vulnérabilités graves. Ces vulnérabilités découlent principalement d'interactions risquées entre le hook, PoolManager et des tiers externes, et peuvent être divisées en deux catégories: problèmes de contrôle d'accès et problèmes de validation des données d'entrée. Les résultats spécifiques sont présentés dans le tableau ci-dessous:

En résumé, nous avons identifié 22 projets pertinents (à l'exclusion de ceux qui ne sont pas liés à Uniswap v4). Parmi ces projets, nous pensons que 8 (36%) présentent des vulnérabilités. Parmi les 8 projets vulnérables, 6 ont des problèmes de contrôle d'accès et 2 sont vulnérables aux appels externes non fiables.

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

Dans cette partie de la discussion, nous nous concentrons principalement sur les problèmes que les fonctions de rappel dans la version 4 peuvent causer, y compris les 8 fonctions de rappel et la fonction de verrouillage. Bien sûr, il existe d'autres cas qui nécessitent une vérification, mais ils varient selon la conception et sont actuellement hors du champ d'application. Ces fonctions ne devraient être appelables que par le PoolManager, et non par d'autres adresses (y compris les EOAs et les contrats). Par exemple, dans le cas où les récompenses sont distribuées à partir des clés du pool, les récompenses pourraient être réclamées incorrectement si les fonctions correspondantes étaient appelables par des comptes arbitraires. Par conséquent, l'établissement de mécanismes de contrôle d'accès solides est crucial pour les hooks, car ils peuvent être invoqués par des parties autres que les pools eux-mêmes. En gouvernant strictement les autorisations d'accès, les pools de liquidité peuvent réduire de manière significative les risques associés aux interactions non autorisées ou malveillantes avec les hooks.

Problèmes de validation d'entrée 2.1.2

Dans Uniswap v4, en raison du mécanisme de verrouillage, les utilisateurs doivent obtenir un verrou via un contrat avant d'exécuter des opérations de pool. Cela garantit que le contrat actuellement en interaction est le dernier contrat de verrouillage. Néanmoins, il existe toujours un scénario d'attaque potentiel d'appels externes non fiables en raison d'une validation d'entrée incorrecte dans certaines implémentations de Hook vulnérables :

• Tout d'abord, le crochet ne vérifie pas le pool avec lequel l'utilisateur a l'intention d'interagir. Il pourrait s'agir d'un pool malveillant avec des jetons factices exécutant une logique nuisible.
• Deuxièmement, certaines fonctions de crochet 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 les attaques de rentrée bien connues. Pour attaquer ces hooks vulnérables, l'attaquant peut enregistrer un pool malveillant avec de faux jetons pour eux-mêmes, puis invoquer le hook pour exécuter des opérations sur le pool. Lors de l'interaction avec le pool, la logique de jeton malveillant détourne le flux de contrôle pour des actes répréhensibles.

2.1.3 Contremesures pour le Modèle de Menace I

Pour contourner de telles questions de sécurité liées aux crochets, il est essentiel d'exécuter correctement le contrôle d'accès nécessaire sur les fonctions externes/publiques sensibles et de valider les entrées pour vérifier les interactions. De plus, des gardes de réentrance peuvent aider à garantir que les crochets ne sont pas réentrés pendant les flux logiques standard. En mettant en place des mesures de sécurité appropriées, les pools peuvent 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 crochet sont malveillants. Compte tenu de la portée large, nous nous concentrons uniquement sur les problèmes de sécurité liés à la version 4. La clé réside alors dans la capacité des crochets fournis à gérer les transferts d'utilisateurs ou les autorisations de cryptomonnaies. Puisque la méthode d'accès aux crochets détermine les autorisations pouvant être accordées aux crochets, nous catégorisons les crochets en deux types en fonction de cela :

• Hooks managés : le hook n’est pas un point d’entrée. Les utilisateurs doivent interagir avec le hook via un routeur (éventuellement fourni par Uniswap).
• Crochets autonomes：Le crochet est un point d'entrée, permettant aux utilisateurs d'interagir directement avec lui.

Figure 2 : Exemple de crochet malveillant

2.2.1 Crochets Gérés

Dans ce cas, les actifs de cryptomonnaie des utilisateurs (y compris les jetons natifs et autres jetons) sont transférés ou approuvés vers le routeur. Comme le PoolManager effectue des vérifications de solde, les hooks malveillants ne volent pas facilement ces actifs directement. Cependant, des surfaces d'attaque potentielles existent toujours. Par exemple, le mécanisme de gestion des frais dans la version 4 peut être manipulé par un attaquant via des hooks.

Crochets autonomes 2.2.2

Lorsque les crochets sont utilisés comme points d'entrée, la situation devient plus complexe. Ici, puisque les utilisateurs peuvent interagir directement avec le crochet, le crochet se voit accorder plus de puissance. En théorie, le crochet peut exécuter toutes les opérations désirées à travers de telles interactions. Dans la version 4, la vérification de la logique du code est extrêmement critique. Le principal problème est de savoir si la logique du code peut être manipulée. Si le crochet est modifiable, cela signifie qu'un crochet qui semble sécurisé peut devenir malveillant après une mise à jour, présentant des risques importants. Ces risques comprennent :

• Proxies évolutifs (qui peuvent être directement attaqués)
• Logique avec auto-destructeurs. Peut être attaquée en conjonction avec l'appel de selfdestruct et create2.

2.2.3 Contremesures pour le modèle de menace II

Un point essentiel est d'évaluer si les hooks sont malveillants. Plus précisément, pour les hooks gérés, nous devrions être attentifs au comportement de gestion des frais ; tandis que pour les hooks autonomes, l'accent principal est mis sur leur capacité à être mis à niveau.

- 3 - Conclusion

Dans cet article, nous avons d'abord brièvement décrit les mécanismes de base liés aux problèmes de sécurité du crochet Uniswap v4. Nous avons ensuite proposé deux modèles de menace et brièvement décrit les risques de sécurité associés. Dans les articles suivants, nous effectuerons des analyses approfondies des problèmes de sécurité sous chaque modèle de menace. Restez à l'écoute!

Références

[1] Notre vision pour Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Brouillon du livre blanc 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] Exemples de crochet
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Super Crochets Uniswap v4 impressionnants
https://github.com/fewwwww/awesome-uniswap-hooks

[6] Vulnérabilité UUPSUpgradeable Post-mortem
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

À propos de BlocSec BlocSec est une entreprise mondiale de sécurité blockchain de premier plan fondée en 2021 par des experts renommés de l'industrie de la sécurité. La société est dédiée à l'amélioration de la sécurité et de la convivialité pour le monde Web3 afin de promouvoir l'adoption généralisée de Web3. Pour ce faire, BlockSec propose des services d'audit de sécurité des contrats intelligents et de la chaîne EVM, un système de développement, de test et d'interception des pirates appelé Phalcon pour les propriétaires de projets, une plateforme de suivi des fonds et d'investigation appelée MetaSleuth, ainsi que des plugins d'efficacité pour les constructeurs web3 appelés MetaDock. À l'heure actuelle, l'entreprise a servi plus de 300 clients, dont des projets bien connus tels que MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, et a reçu deux tours de financement totalisant plus de dizaines de millions de dollars de la part d'institutions d'investissement telles que Oasis Capital, IDG Capital et Distributed Capital. Page d'accueil：www.blocsec.com

Twitter：https://twitter.com/BlocSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock :https://blocksec.com/metadock

Avertissement：

1. Cet article est repris de [BlocBlocSec]. Tous les droits d'auteur appartiennent à l'auteur original [BlocSec]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.