Hoskinson alerte sur les risques du code de délégation d'Ethereum alors que le débat sur l'EIP-7702 s'intensifie
Charles Hoskinson tire la sonnette d'alarme sur les risques potentiels liés à l'EIP-7702, le liant à une récente attaque sur un portefeuille de Binance. Découvrez les préoccupations en matière de sécurité soulevées par cette analyse.

Analyse de Charles Hoskinson sur la sécurité d'Ethereum
Le fondateur de Cardano, Charles Hoskinson, a mis en garde contre un "code sérieusement dangereux" en partageant une analyse qui attribue à la fonctionnalité de délégation EIP-7702 d'Ethereum la responsabilité d'avoir permis à des attaquants de vider rapidement un portefeuille chaud de Binance. Dans son post sur X, Hoskinson a écrit :
"Attention, il y a un code sérieusement dangereux là-dehors,"en référence à une analyse publiée par CyberSatoshi.
Ce post décrivait le bytecode reconstruit d'un prétendu balayeur EIP-7702 de Binance, arguant que le contrat était adapté aux opérations de l'échange. Cependant, le message de Hoskinson n'a pas identifié de faille de protocole spécifique ni expliqué quelle partie de l'analyse il soutenait.
Questions de sécurité soulevées
Le compte de CyberSatoshi a mis en lumière deux questions de sécurité. La première concerne la manière dont un attaquant a obtenu la permission d'agir sur le portefeuille, tandis que la seconde se penche sur ce que la fonctionnalité de délégation d'Ethereum a permis à l'attaquant de faire après avoir obtenu cette permission. Selon l'analyse de CyberSatoshi, le contrat reconstruit laissait exactement 1 ETH dans le portefeuille lors du balayage de son solde natif. Cela aurait empêché la file d'attente automatique du portefeuille chaud de Binance d'échouer en raison d'un gaz insuffisant, évitant ainsi de déclencher des alarmes.
L'analyse décrivait une boucle de traitement de jetons qui vérifiait les soldes par le biais d'appels de bas niveau et continuait même lorsque certaines opérations échouaient. CyberSatoshi a déclaré que cela permettait au balayeur de continuer à traiter des actifs, même si un jeton sur liste noire ou autrement non réactif ne pouvait pas être transféré. Une fonction d'exécution personnalisée aurait prétendument permis au portefeuille compromis d'appeler un coffre externe détenant 823 millions de dollars en USDC.
Dans l'explication de l'afficheur, le coffre reconnaissait Binance 14 comme son contrôleur, permettant ainsi aux appels effectués par ce portefeuille d'accéder à des fonds en dehors de son solde immédiat. CyberSatoshi a caractérisé le contrat comme étant spécifiquement conçu pour l'architecture de Binance.
Spécifications de l'EIP-7702
La spécification EIP-7702 d'Ethereum décrit un type de transaction qui permet à un compte détenu de manière externe de déléguer l'exécution à un code déployé à une autre adresse. Un compte détenu de manière externe fonctionne normalement par le biais de signatures de sa clé privée. La délégation lui permet d'exécuter la logique des contrats intelligents dans le contexte de son propre compte, soutenant des fonctionnalités telles que le regroupement de plusieurs opérations en une seule transaction et permettant à un autre compte de payer les frais de transaction.
Chaque autorisation identifie une chaîne, une adresse de délégué et un nonce, ainsi qu'une signature cryptographique. Le protocole récupère le compte autorisant à partir de cette signature et vérifie son nonce avant d'appliquer la délégation.
CyberSatoshi a reconnu cette exigence, affirmant que l'attaque alléguée nécessitait soit la clé privée brute, soit un accès de signature illimité à l'infrastructure de sécurité de Binance 14. La spécification n'établit pas comment les identifiants de signature de Binance ont été obtenus. Son exigence de signature stipule que la délégation ne peut pas simplement être attribuée à un compte victime arbitraire sans autorisation valide.
Conclusion sur les implications de la délégation
CyberSatoshi a affirmé que l'attaquant avait soumis 50 autorisations pré-signées couvrant des nonces consécutifs pour piéger Binance 14 pendant que son nombre de transactions changeait. La spécification traite les autorisations dans l'ordre. Lorsqu'une autorisation échoue à un contrôle, le traitement continue avec l'entrée suivante. Une entrée valide définit la délégation et incrémente le nonce du compte autorisant.
Les auteurs de l'EIP avertissent explicitement que le code autorisé a un accès illimité au compte et doit être étroitement audité par le portefeuille. Sa section de sécurité énumère les protections nécessaires pour les contrats de délégués, y compris la prévention des rejets et des signatures couvrant la valeur de la transaction, le gaz, la destination et les données d'appel. Une délégation mal implémentée peut laisser un attaquant avec un contrôle presque complet sur le compte de signature.
La spécification indique en outre qu'un échec d'exécution ne fait pas revenir les indicateurs de délégation déjà traités. Pour supprimer la délégation, le protocole permet une autorisation valide pointant vers l'adresse zéro, ce qui efface le code de délégation du compte.