Cette distinction est importante pour les portefeuilles chauds des plateformes d’échange et les trésoreries dont les contrôles supposent qu’ils ne signent que des transactions ordinaires. Comme l’a précédemment rapporté The Defiant, le co-PDG de Binance, Richard Teng, a déclaré que l’attaquant à l’origine de la faille avait utilisé EIP-7702 pour obtenir une approbation d’exécution sur un portefeuille chaud. « Cette délégation n’est pas passée par nos contrôles d’approbation habituels », a-t-il déclaré.
Une transaction onchain enregistrée par Etherscan montre un appel unique à Binance 14, transférant environ 167464 ETH et 1,615 milliard USDT, ainsi que d’autres jetons, à l’attaquant.
Un interrupteur à sens unique
Le projet de spécification réutiliserait une forme actuellement invalide de la transaction de type 4 d’EIP-7702 : une transaction adressée à elle-même, avec une valeur nulle, aucune donnée et des listes d’accès et d’autorisations vides. Elle installerait un marqueur non exécutable de trois octets, provisoirement `0xef0200`, sans exécuter aucun code délégué existant.
Une fois installé, le marqueur ferait ignorer les futures autorisations de délégation, y compris les tentatives de l’effacer. Le compte conserverait son adresse, les transferts ordinaires et les appels de contrats, tandis que les appels entrants n’exécuteraient aucun code. Les frais fixes proposés sont de 33500 gas, et l’auteur précise qu’ils n’ont pas fait l’objet de tests de performance.
La protection se limite à la délégation. Une clé privée compromise pourrait toujours transférer des fonds, accorder des autorisations de jetons ou signer des autorisations de contrat. Les autorisations existantes ne seraient pas révoquées. Le projet avertit également que le refus de la délégation pourrait désactiver la récupération qui en dépend ou rendre inaccessibles les actifs nécessitant le code de l’ancien délégué.
L’expiration vise un autre risque
Un autre projet de Joseph Delong, dans la PR #12601, exigerait que chaque autorisation signe une référence de bloc faisant partie des 256 blocs ancêtres précédant le bloc d’inclusion. Cela limiterait la période pendant laquelle les autorisations inutilisées peuvent être appliquées, sans faire expirer une délégation déjà installée.
Un autre projet, EIP-7851, adopte une approche différente : désactiver définitivement l’autorité de la clé de signature d’origine au niveau du protocole, tout en laissant le code du portefeuille modifier la délégation. La nouvelle option de refus préserve plutôt les pouvoirs de transaction ordinaires de la clé et supprime la capacité de délégation.
La conception de cette option de refus nécessite encore des travaux de compatibilité. L’encodage du marqueur est provisoire, et les contrats ou portefeuilles qui identifient les comptes ordinaires par l’absence de code pourraient rejeter les comptes marqués. Les portefeuilles et les dispositifs de signature matérielle devraient également reconnaître cette nouvelle forme de transaction et la présenter comme irréversible.