Temps de lecture: 5 minutes

Le monde du Web3 est un monde de protocoles et de normes. Vous devez certainement avoir rencontré plusieurs normes ERC. Certaines des normes ERC les plus connues sont 20 et 721, qui concernent respectivement les jetons et NFT. Mais Web3 ne se limite pas à cela.

Nous voyons des mises à jour et des mises à niveau régulières dans Web3. L'une des dernières mises à jour était ERC 4337, déployée sur Ethereum Mainnet en mars 2023. Toutes les mises à jour ne réussissent pas en une seule fois ; il en va de même avec ERC 4337. Dans ce blog, nous découvrirons les vulnérabilités concernant la section User Operation de la norme et leur impact. Commençons tout d'abord par une brève introduction à la norme ERC 4337.

Qu'est-ce que l'ERC 4337 ?

Contrairement au réseau de Bitcoin, Ethereum prend en charge les contrats intelligents sur la chaîne, ce qui fait qu'Ethereum a deux types de comptes différents, un compte transactionnel ou un compte opérationnel. En plus de cela, les contrats intelligents ont leur propre espace, presque comme un compte. Ces deux types de comptes dans Ethereum ont leurs propres fonctionnalités. 

La plupart des portefeuilles fonctionnant avec Ethereum sont des EOA, ce qui signifie les comptes de l'utilisateur, pas les contrats intelligents. Ces types de comptes ont leurs propres limites. Une limitation comprend la seule dépendance de l'utilisateur aux clés privées pour accéder aux comptes et l'exigence de toutes les signatures pour les transactions. Ces limitations ont incité l'introduction de l'ERC 4337.

L'ERC 4337 tente de fournir une abstraction de compte en combinant le meilleur des deux fonctionnalités de type de compte. Oui, EOA et comptes de contrats intelligents. Ceci est rendu possible par un contrat unique qui peut traiter des jetons et créer des contrats simultanément, et ERC 4337 est une norme facilitant cette nouvelle avancée impressionnante.

Vulnérabilité de l'emballage UserOperation ?

Tout dans cette norme et ce projet est génial, mais qu'est-ce qui n'a pas fonctionné ? Eh bien, il y a eu un problème d'implémentation qui a entraîné des hachages incohérents en fonction de la méthode utilisée pour signer. Cela a conduit à des conflits d'ordre, en particulier des hachages divergents pour les mêmes UserOperations et des hachages en collision pour différentes UserOperations.

Les régions concernées se limitaient à deux vulnérabilités, la vulnérabilité EntryPoint Packing et la vulnérabilité VerifyingPaymaster Packing. Plus sur cela plus tard. Ayons d'abord une compréhension générale, puis nous en apprendrons individuellement.

Jetons un coup d'œil à UserOperation.sol : -

Vous voyez le paramètre UserOperation, un Calldata, passé comme argument à la fonction pack. Explorons la structure : -

Ce sont les champs que porte la structure UserOperation. Pour copier cette grande partie des données d'appel en mémoire, les segments de code utilisent l'assemblage. Certaines méthodes des contrats visent à capturer tous les champs de l'UserOperation, y compris les champs de taille variable, également appelés champs dynamiques dans l'encodage ABI. Par exemple, l'encodage dynamique dans cette structure est 'initCode', 'callData' et 'paymasterAndData'.

Certaines méthodes ne peuvent pas inclure 'paymasterAndData' car ce champ n'est pas encore défini ou déclaré. Les méthodes utilisent le champ de commodité '.offset' fourni aux types de données dynamiques pour ce faire. Mais les contrats qui utilisent des arguments codés en ABI ne valident pas l'ordre dans lequel les champs sont définis et la validité des décalages. Il est possible de construire une représentation valide des opérations de l'utilisateur dans Calldata avec des propriétés de hachage inhabituelles. 

Vulnérabilité de l'emballage EntryPoint

Le problème avec UserOperation affecte également certaines des autres parties de la norme, la vulnérabilité EntryPoint Packing en fait partie. Lorsqu'un schéma de hachage différent est utilisé entre le contrat EntryPoint et le portefeuille ou qu'un encodage d'opération utilisateur non standard est utilisé, nous constatons une divergence de hachage.

Le risque apparaît comme EntryPoint. Désormais, une opération d'utilisateur unique peut être représentée par plusieurs "hachages d'opération utilisateur", et le même "hachage d'opération utilisateur" peut représenter plusieurs opérations utilisateur. Maintenant, cela peut créer des effets indésirables. Discutons de l'impact que cela peut avoir.

L'Erc 4337 est encore à un stade très précoce, car il vient d'être publié en mars, de sorte que l'impact de ces vulnérabilités n'est pas entièrement connu. Il est difficile de décrire l'impact potentiel à vol d'oiseau. Au-delà de cela, l'impact dépend de la mise en œuvre de bundlers, d'indexeurs, d'explorateurs d'opérations utilisateur et d'autres services hors chaîne. Examinons quelques-uns des problèmes causés par cette vulnérabilité.

1. Cela peut entraîner une expérience déroutante pour l'utilisateur, car le hachage de l'opération utilisateur peut changer entre le moment de la soumission et celui de l'inclusion. Ce phénomène est inconnu de la plupart des portefeuilles, ils pourraient donc ne pas expliquer cette différence.

2. Les portefeuilles peuvent être modifiés et conçus pour éviter intentionnellement l'indexation en configurant tous les hachages d'opérations de l'utilisateur pour qu'ils soient identiques.

3. Nous pouvons voir une mauvaise gestion des données et des clés si un service hors chaîne surveillant l'inclusion de l'opération utilisateur manque l'inclusion d'une opération utilisateur donnée.

Vérification de la vulnérabilité de l'emballage Paymaster

Personne n'aime commander quelque chose en ligne et recevoir un produit complètement différent. Il en va de même sur Web3, mais cette vulnérabilité dégrade l'expérience utilisateur. Un utilisateur peut avoir des contenus modifiés ou différents entre le moment de la signature et l'inclusion sur la chaîne. Et la raison pour laquelle cela se produit est que deux opérations utilisateur différentes renvoient le même hachage à partir de la fonction 'VerifyingPaymaster.getHash()'.

La fonction VerifyingPaymaster.getHash() prend quelques arguments comme 'UserOperation', qui est une structure, 'validUnitl', une valeur uint48 et un validAfter une autre valeur uint48. La question des différents contenus entre le temps de signature et le temps d'inclusion impacte l'expérience utilisateur et la sécurité globale. Discutons de quelques-unes des préoccupations qu'il soulève.

1. Les signataires hors chaîne qui signent dans un format codé ABI après avoir reçu des opérations utilisateur ou les signataires avec des intégrations de contrat pour préparer les données pour la signature deviennent vulnérables. 

2. Le hachage peut être modifié pour couvrir moins d'éléments que prévu, ce qui peut entraîner l'exclusion de certains champs statiques, comme initCode, etc., du hachage. Cela peut entraîner une utilisation différente de celle prévue pour les signatures de parrainage payeur.

3. Nous pouvons constater une violation et un contournement des règles en modifiant userOp.initCode et userOp.callData après avoir obtenu une signature. Cela permettra au jeton natif du payeur d'être utilisé à des fins autres que la frappe de NFT sans gaz.

Conclusion

Avec l'avancement et le développement continus, nous assisterons à de nombreuses choses impressionnantes, et l'ERC 4337 en fait partie. Alors que développer et faire progresser la sécurité est quelque chose que nous ne pouvons jamais compromettre. Il est impressionnant de noter la rapidité avec laquelle les vulnérabilités ont été trouvées dans la norme, et la recherche et le développement continus sont menés pour la sécuriser.

Il est important de noter que même certaines des organisations les plus importantes et les plus connues construites dans Web3 peuvent commettre des erreurs liées à la sécurité, et les autres protocoles en font sûrement aussi. La hausse continue de Incidents Web3 ces dernières années est évidente. 

La solution unique pour vous protéger, vous, vos utilisateurs et votre protocole contre de telles menaces de sécurité va faire l'objet d'un audit. Nous, QuillAudits, sommes l'un des meilleurs fournisseurs de services en matière d'audit de contrats intelligents et de sécurité de la blockchain. Visitez notre site Web pour en savoir plus et sécuriser votre projet. Et restez à l'écoute pour profiter de plus de ces blogs informatifs

31 Vues

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• Frapper l'avenir avec Adryenn Ashley. Accéder ici.
• La source: https://blog.quillhash.com/2023/04/24/understanding-erc-4337-user-operation-packing-vulnerability/