La dualité du mécanisme Hook d'Uniswap v4 : innovation et risques potentiels coexistent
Uniswap v4 sera bientôt lancé, et cette mise à niveau est ambitieuse. La nouvelle version introduira plusieurs nouvelles fonctionnalités, y compris le soutien d'un nombre illimité de pools de liquidité par paire de négociation et de frais dynamiques, un design singleton, une comptabilité instantanée, un mécanisme Hook, ainsi que le soutien à la norme de jeton ERC1155. En utilisant la technologie de stockage transitoire, Uniswap v4 devrait être publié après la mise à niveau Ethereum Cancun.
Parmi de nombreuses innovations, le mécanisme Hook attire une attention particulière en raison de son potentiel puissant. Ce mécanisme permet d'exécuter du code personnalisé à des points spécifiques du cycle de vie des pools de liquidité, améliorant ainsi considérablement l'évolutivité et la flexibilité des pools.
Cependant, le mécanisme Hook peut également être une arme à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée de Hook présente également des défis importants. La complexité de Hook entraîne inévitablement de nouveaux vecteurs d'attaque potentiels. Il est donc nécessaire de présenter systématiquement les problèmes de sécurité et les risques potentiels associés au mécanisme Hook, afin de promouvoir le développement sécurisé de la communauté, ces idées aideront à construire un Uniswap v4 Hook plus sûr.
Cet article présentera les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité qui y sont associés.
Mécanisme d'Uniswap V4
Avant d'approfondir le sujet, nous devons avoir une compréhension de base du mécanisme d'Uniswap v4. Selon les annonces officielles et le livre blanc, Hook, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités importantes pour réaliser des pools de liquidité personnalisés et un routage efficace entre plusieurs pools.
1.1 Crochet
Hook fait référence à un contrat fonctionnant à différents stades du cycle de vie d'un pool de liquidités. L'équipe d'Uniswap espère qu'en introduisant Hook, tout le monde pourra prendre des décisions équilibrées. Cette méthode permet de prendre en charge nativement des frais dynamiques, d'ajouter des ordres à prix limité sur la chaîne, ou de disperser de grands ordres via un teneur de marché à moyenne pondérée dans le temps (TWAMM).
Il y a actuellement huit rappels Hook, répartis en quatre groupes ( chaque groupe contenant une paire de rappels ):
avantInitialiser/aprèsInitialiser
avantModifierPosition/aprèsModifierPosition
avantÉchange/aprèsÉchange
avantDon/ aprèsDon
L'équipe Uniswap a fourni quelques exemples ( tels que le Hook TWAMM ) qui présente comment l'utiliser, et les participants de la communauté ont également apporté leur contribution. La documentation officielle a également lié au dépôt Awesome Uniswap v4 Hooks, qui recueille davantage d'exemples de Hooks.
1.2 Singleton, comptabilité instantanée et mécanisme de verrouillage
L'architecture singleton et la comptabilité lightning visent à améliorer les performances en réduisant les coûts et en assurant l'efficacité. Elle introduit un nouveau contrat singleton, où tous les pools de liquidité sont conservés dans le même contrat intelligent. Ce design singleton s'appuie sur le PoolManager pour stocker et gérer l'état de tous les pools.
La version v4 d'Uniswap introduit la comptabilité instantanée et le mécanisme de verrouillage. Le fonctionnement du mécanisme de verrouillage est le suivant:
Le contrat locker demande un lock sur le PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file d'attente lockData et appelle son rappel lockAcquired.
Le contrat locker exécute sa logique dans le rappel. Pendant le processus d'exécution, l'interaction du contrat locker avec le pool peut entraîner un accroissement monétaire non nul. Mais à 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 exécuter des opérations.
PoolManager vérifie l'état de la file d'attente lockData et de l'augmentation des devises. Après vérification, PoolManager supprimera ce contrat de locker.
En résumé, le mécanisme de verrouillage empêche l'accès concurrent et garantit que toutes les transactions peuvent être réglées. Le contrat locker 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 opérationnel concerne le solde net interne (, c'est-à-dire delta ), et non l'exécution d'un transfert instantané. Toute modification sera enregistrée dans le solde interne du pool, le transfert réel ayant lieu à la fin de l'opération (, c'est-à-dire lock ). Ce processus garantit qu'il n'y a pas de jetons non liquidés, maintenant ainsi l'intégrité des fonds.
En raison de l'existence d'un mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Au lieu de cela, toute interaction doit se faire via un contrat. Ce contrat agit en tant que locker intermédiaire, et une demande de verrouillage est nécessaire avant d'effectuer toute opération sur le pool.
Il existe principalement deux scénarios d'interaction des contrats :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Cette situation peut être considérée comme une interaction via un routeur.
Le contrat locker et Hook sont intégrés dans le même contrat, ou contrôlés par une entité tierce. Ce cas peut être considéré comme une interaction via Hook. À ce moment-là, 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 cas suivants :
Modèle de menace I : Hook lui-même est bénin, mais il présente des vulnérabilités.
Modèle de menace II : Hook est lui-même malveillant.
Nous allons maintenant discuter 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 à Hook lui-même. Ce modèle de menace suppose que les développeurs et leur Hook sont sans malveillance. Cependant, les vulnérabilités connues existantes des contrats intelligents peuvent également apparaître dans Hook. Par exemple, si Hook est mis en œuvre en tant que contrat évolutif, il pourrait rencontrer des problèmes similaires à ceux des vulnérabilités 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, le Hook est un contrat intelligent capable d'exécuter une logique personnalisée avant ou après l'initialisation, la modification de position, l'échange et la collecte de ( dans le pool central. Bien que le Hook devrait mettre en œuvre 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 du Hook. Ensuite, nous essaierons d'identifier les sources potentielles de vulnérabilités, par exemple, comment le Hook pourrait abuser de ces fonctions standard du Hook.
Plus précisément, nous allons nous concentrer sur les deux types de Hook suivants:
Le premier type de hook, la 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, stockant des données d'état critiques sur lesquelles les utilisateurs ou d'autres protocoles dépendent. Dans ce cas, l'attaquant pourrait essayer de changer cet état critique. Lorsque d'autres utilisateurs ou protocoles utilisent un état incorrect, cela pourrait entraîner des risques potentiels.
Veuillez noter que les crochets en dehors de ces deux plages ne sont pas dans le champ de notre discussion.
Après une étude approfondie du dépôt Awesome Uniswap v4 Hooks, nous avons découvert plusieurs vulnérabilités graves. Ces vulnérabilités proviennent principalement des interactions de risque entre les hooks, le PoolManager et des tiers externes, et peuvent être classées en deux catégories principales : problèmes de contrôle d'accès et problèmes de validation des entrées.
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'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 les 8 rappels hook et le rappel de verrouillage. Bien sûr, il existe d'autres cas à valider, mais ces cas varient en fonction de la conception et ne relèvent pas de notre discussion.
Ces fonctions ne devraient être appelées que par le PoolManager et ne peuvent pas être appelées par d'autres adresses ###, y compris EOA et contrat (. Par exemple, dans le cas où les récompenses sont distribuées par la clé du pool de fonds, si la fonction correspondante peut être appelée par n'importe quel compte, les récompenses pourraient être perçues par erreur.
Par conséquent, il est essentiel pour les hooks 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 permissions d'accès, les pools de liquidité peuvent réduire considérablement les risques d'interaction non autorisée ou malveillante 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 impliqué dans l'interaction est le dernier contrat de verrouillage.
Néanmoins, il existe un scénario d'attaque potentiel, à savoir des appels externes non fiables résultant d'une validation des entrées inadéquate 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. Cela pourrait être un pool de fonds malveillant contenant des jetons faux 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 les attaques de réentrance que nous connaissons bien.
Pour attaquer ces hooks vulnérables, un attaquant peut enregistrer un pool de liquidités malveillant pour son propre faux token, puis appeler le hook pour exécuter des opérations dans le pool de liquidités. Lors de l'interaction avec le pool, la logique du token malveillant prend le contrôle du flux d'exécution afin de mener des actions malveillantes.
2.1.3 Mesures de prévention contre le modèle de menace I
Pour éviter de tels problèmes de sécurité liés aux hooks, il est crucial d'exécuter correctement les contrôles d'accès nécessaires sur les fonctions externes/publiques sensibles et de valider les paramètres d'entrée afin de vérifier les interactions. 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 protection appropriées, le pool de fonds peut réduire les risques associés à de telles menaces.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?]###https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 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 nous concentrerons uniquement sur les problèmes de sécurité liés à la version v4. Par conséquent, la clé réside dans la capacité du hook fourni à gérer les actifs cryptographiques des utilisateurs lors des transferts ou des autorisations.
Étant donné que la méthode d'accès au hook détermine les autorisations qui peuvent être accordées au hook, nous classons donc les hooks en deux catégories:
Hook géré ### Managed Hooks ( : le hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec le hook via le routeur ) qui peut être fourni par Uniswap (.
Crochets autonomes ) : le hook est un point d'entrée qui permet aux utilisateurs d'interagir directement.
(# 2.2.1 Hook de type hébergement
Dans ce cas, les actifs cryptographiques de l'utilisateur ) comprennent des jetons natifs et d'autres jetons ### qui sont transférés ou autorisés au routeur. Étant donné que le PoolManager effectue une vérification des soldes, il est difficile pour un hook malveillant de voler directement ces actifs. Cependant, il existe toujours des surfaces d'attaque potentielles. 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 l'utilisateur peut interagir directement avec le hook, celui-ci acquiert plus de pouvoir. En théorie, le hook peut exécuter n'importe quelle opération souhaitée grâce à 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é pourrait devenir malveillant après une mise à niveau, ce qui constituerait un risque majeur. Ces risques incluent :
Un proxy évolutif ) peut être directement attaqué ###;
Possède une logique d'auto-destruction. Peut être attaqué en cas d'appel conjoint de 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 ; tandis que pour les hooks indépendants, le principal point d'attention est de savoir s'ils sont évolutifs.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?])https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp###
Conclusion
Cet article présente d'abord un aperçu des mécanismes centraux liés aux problèmes de sécurité des Hooks d'Uniswap v4. Ensuite, nous proposons deux modèles de menace et résumons brièvement les risques de sécurité associés.
Dans les articles suivants, nous procéderons à une analyse approfondie des problèmes de sécurité sous chaque modèle de menace.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
16 J'aime
Récompense
16
5
Partager
Commentaire
0/400
OfflineValidator
· 07-31 11:18
Il faut vraiment comprendre V4.
Voir l'originalRépondre0
MetaMisery
· 07-30 04:35
C'est moins stable que v3, vous voulez encore spéculer sur le concept, n'est-ce pas ?
Voir l'originalRépondre0
SatoshiNotNakamoto
· 07-30 04:24
J'attends que le bug de la v4 apparaisse.
Voir l'originalRépondre0
TokenGuru
· 07-30 04:17
Ancienne version du projet, les pigeons qui montent à bord sans réfléchir vont encore subir des pertes.
Voir l'originalRépondre0
SigmaValidator
· 07-30 04:16
Compris, cette opportunité de shorting est pas mal.
Analyse de la sécurité du mécanisme Hook de Uniswap v4 : innovation et risques coexistent
La dualité du mécanisme Hook d'Uniswap v4 : innovation et risques potentiels coexistent
Uniswap v4 sera bientôt lancé, et cette mise à niveau est ambitieuse. La nouvelle version introduira plusieurs nouvelles fonctionnalités, y compris le soutien d'un nombre illimité de pools de liquidité par paire de négociation et de frais dynamiques, un design singleton, une comptabilité instantanée, un mécanisme Hook, ainsi que le soutien à la norme de jeton ERC1155. En utilisant la technologie de stockage transitoire, Uniswap v4 devrait être publié après la mise à niveau Ethereum Cancun.
Parmi de nombreuses innovations, le mécanisme Hook attire une attention particulière en raison de son potentiel puissant. Ce mécanisme permet d'exécuter du code personnalisé à des points spécifiques du cycle de vie des pools de liquidité, améliorant ainsi considérablement l'évolutivité et la flexibilité des pools.
Cependant, le mécanisme Hook peut également être une arme à double tranchant. Bien qu'il soit puissant et flexible, l'utilisation sécurisée de Hook présente également des défis importants. La complexité de Hook entraîne inévitablement de nouveaux vecteurs d'attaque potentiels. Il est donc nécessaire de présenter systématiquement les problèmes de sécurité et les risques potentiels associés au mécanisme Hook, afin de promouvoir le développement sécurisé de la communauté, ces idées aideront à construire un Uniswap v4 Hook plus sûr.
Cet article présentera les concepts liés au mécanisme Hook dans Uniswap v4 et décrira les risques de sécurité qui y sont associés.
Mécanisme d'Uniswap V4
Avant d'approfondir le sujet, nous devons avoir une compréhension de base du mécanisme d'Uniswap v4. Selon les annonces officielles et le livre blanc, Hook, l'architecture singleton et la comptabilité instantanée sont trois fonctionnalités importantes pour réaliser des pools de liquidité personnalisés et un routage efficace entre plusieurs pools.
1.1 Crochet
Hook fait référence à un contrat fonctionnant à différents stades du cycle de vie d'un pool de liquidités. L'équipe d'Uniswap espère qu'en introduisant Hook, tout le monde pourra prendre des décisions équilibrées. Cette méthode permet de prendre en charge nativement des frais dynamiques, d'ajouter des ordres à prix limité sur la chaîne, ou de disperser de grands ordres via un teneur de marché à moyenne pondérée dans le temps (TWAMM).
Il y a actuellement huit rappels Hook, répartis en quatre groupes ( chaque groupe contenant une paire de rappels ):
L'équipe Uniswap a fourni quelques exemples ( tels que le Hook TWAMM ) qui présente comment l'utiliser, et les participants de la communauté ont également apporté leur contribution. La documentation officielle a également lié au dépôt Awesome Uniswap v4 Hooks, qui recueille davantage d'exemples de Hooks.
1.2 Singleton, comptabilité instantanée et mécanisme de verrouillage
L'architecture singleton et la comptabilité lightning visent à améliorer les performances en réduisant les coûts et en assurant l'efficacité. Elle introduit un nouveau contrat singleton, où tous les pools de liquidité sont conservés dans le même contrat intelligent. Ce design singleton s'appuie sur le PoolManager pour stocker et gérer l'état de tous les pools.
La version v4 d'Uniswap introduit la comptabilité instantanée et le mécanisme de verrouillage. Le fonctionnement du mécanisme de verrouillage est le suivant:
Le contrat locker demande un lock sur le PoolManager.
PoolManager ajoute l'adresse du contrat locker à la file d'attente lockData et appelle son rappel lockAcquired.
Le contrat locker exécute sa logique dans le rappel. Pendant le processus d'exécution, l'interaction du contrat locker avec le pool peut entraîner un accroissement monétaire non nul. Mais à 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 exécuter des opérations.
PoolManager vérifie l'état de la file d'attente lockData et de l'augmentation des devises. Après vérification, PoolManager supprimera ce contrat de locker.
En résumé, le mécanisme de verrouillage empêche l'accès concurrent et garantit que toutes les transactions peuvent être réglées. Le contrat locker 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 opérationnel concerne le solde net interne (, c'est-à-dire delta ), et non l'exécution d'un transfert instantané. Toute modification sera enregistrée dans le solde interne du pool, le transfert réel ayant lieu à la fin de l'opération (, c'est-à-dire lock ). Ce processus garantit qu'il n'y a pas de jetons non liquidés, maintenant ainsi l'intégrité des fonds.
En raison de l'existence d'un mécanisme de verrouillage, tous les comptes externes (EOA) ne peuvent pas interagir directement avec PoolManager. Au lieu de cela, toute interaction doit se faire via un contrat. Ce contrat agit en tant que locker intermédiaire, et une demande de verrouillage est nécessaire avant d'effectuer toute opération sur le pool.
Il existe principalement deux scénarios d'interaction des contrats :
Le contrat locker provient de la bibliothèque de code officielle ou est déployé par l'utilisateur. Cette situation peut être considérée comme une interaction via un routeur.
Le contrat locker et Hook sont intégrés dans le même contrat, ou contrôlés par une entité tierce. Ce cas peut être considéré comme une interaction via Hook. À ce moment-là, 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 cas suivants :
Modèle de menace I : Hook lui-même est bénin, mais il présente des vulnérabilités.
Modèle de menace II : Hook est lui-même malveillant.
Nous allons maintenant discuter 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 à Hook lui-même. Ce modèle de menace suppose que les développeurs et leur Hook sont sans malveillance. Cependant, les vulnérabilités connues existantes des contrats intelligents peuvent également apparaître dans Hook. Par exemple, si Hook est mis en œuvre en tant que contrat évolutif, il pourrait rencontrer des problèmes similaires à ceux des vulnérabilités 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, le Hook est un contrat intelligent capable d'exécuter une logique personnalisée avant ou après l'initialisation, la modification de position, l'échange et la collecte de ( dans le pool central. Bien que le Hook devrait mettre en œuvre 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 du Hook. Ensuite, nous essaierons d'identifier les sources potentielles de vulnérabilités, par exemple, comment le Hook pourrait abuser de ces fonctions standard du Hook.
Plus précisément, nous allons nous concentrer sur les deux types de Hook suivants:
Le premier type de hook, la 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, stockant des données d'état critiques sur lesquelles les utilisateurs ou d'autres protocoles dépendent. Dans ce cas, l'attaquant pourrait essayer de changer cet état critique. Lorsque d'autres utilisateurs ou protocoles utilisent un état incorrect, cela pourrait entraîner des risques potentiels.
Veuillez noter que les crochets en dehors de ces deux plages ne sont pas dans le champ de notre discussion.
Après une étude approfondie du dépôt Awesome Uniswap v4 Hooks, nous avons découvert plusieurs vulnérabilités graves. Ces vulnérabilités proviennent principalement des interactions de risque entre les hooks, le PoolManager et des tiers externes, et peuvent être classées en deux catégories principales : problèmes de contrôle d'accès et problèmes de validation des entrées.
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'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 les 8 rappels hook et le rappel de verrouillage. Bien sûr, il existe d'autres cas à valider, mais ces cas varient en fonction de la conception et ne relèvent pas de notre discussion.
Ces fonctions ne devraient être appelées que par le PoolManager et ne peuvent pas être appelées par d'autres adresses ###, y compris EOA et contrat (. Par exemple, dans le cas où les récompenses sont distribuées par la clé du pool de fonds, si la fonction correspondante peut être appelée par n'importe quel compte, les récompenses pourraient être perçues par erreur.
Par conséquent, il est essentiel pour les hooks 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 permissions d'accès, les pools de liquidité peuvent réduire considérablement les risques d'interaction non autorisée ou malveillante 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 impliqué dans l'interaction est le dernier contrat de verrouillage.
Néanmoins, il existe un scénario d'attaque potentiel, à savoir des appels externes non fiables résultant d'une validation des entrées inadéquate 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. Cela pourrait être un pool de fonds malveillant contenant des jetons faux 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 les attaques de réentrance que nous connaissons bien.
Pour attaquer ces hooks vulnérables, un attaquant peut enregistrer un pool de liquidités malveillant pour son propre faux token, puis appeler le hook pour exécuter des opérations dans le pool de liquidités. Lors de l'interaction avec le pool, la logique du token malveillant prend le contrôle du flux d'exécution afin de mener des actions malveillantes.
2.1.3 Mesures de prévention contre le modèle de menace I
Pour éviter de tels problèmes de sécurité liés aux hooks, il est crucial d'exécuter correctement les contrôles d'accès nécessaires sur les fonctions externes/publiques sensibles et de valider les paramètres d'entrée afin de vérifier les interactions. 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 protection appropriées, le pool de fonds peut réduire les risques associés à de telles menaces.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?]###https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 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 nous concentrerons uniquement sur les problèmes de sécurité liés à la version v4. Par conséquent, la clé réside dans la capacité du hook fourni à gérer les actifs cryptographiques des utilisateurs lors des transferts ou des autorisations.
Étant donné que la méthode d'accès au hook détermine les autorisations qui peuvent être accordées au hook, nous classons donc les hooks en deux catégories:
Hook géré ### Managed Hooks ( : le hook n'est pas un point d'entrée. Les utilisateurs doivent interagir avec le hook via le routeur ) qui peut être fourni par Uniswap (.
Crochets autonomes ) : le hook est un point d'entrée qui permet aux utilisateurs d'interagir directement.
(# 2.2.1 Hook de type hébergement
Dans ce cas, les actifs cryptographiques de l'utilisateur ) comprennent des jetons natifs et d'autres jetons ### qui sont transférés ou autorisés au routeur. Étant donné que le PoolManager effectue une vérification des soldes, il est difficile pour un hook malveillant de voler directement ces actifs. Cependant, il existe toujours des surfaces d'attaque potentielles. 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 l'utilisateur peut interagir directement avec le hook, celui-ci acquiert plus de pouvoir. En théorie, le hook peut exécuter n'importe quelle opération souhaitée grâce à 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é pourrait devenir malveillant après une mise à niveau, ce qui constituerait un risque majeur. Ces risques incluent :
Un proxy évolutif ) peut être directement attaqué ###;
Possède une logique d'auto-destruction. Peut être attaqué en cas d'appel conjoint de 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 ; tandis que pour les hooks indépendants, le principal point d'attention est de savoir s'ils sont évolutifs.
![Pourquoi dit-on que Hook est une "épée à double tranchant" pour Uniswap V4 ?])https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp###
Conclusion
Cet article présente d'abord un aperçu des mécanismes centraux liés aux problèmes de sécurité des Hooks d'Uniswap v4. Ensuite, nous proposons deux modèles de menace et résumons brièvement les risques de sécurité associés.
Dans les articles suivants, nous procéderons à une analyse approfondie des problèmes de sécurité sous chaque modèle de menace.