9 des 10 principales chaînes TVL prennent en charge les contrats intelligents EVM.
Titre original : "Comment utiliser des EVM fourchues pour les risques de sécurité"
撰文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan
Compilateur : Katie Koo
Pour renforcer les garanties de sécurité et de garde pour les clients qui négocient ERC-20 et d'autres actifs basés sur des contrats intelligents, l'équipe Coinbase Blockchain Security a étudié la couche programmatique qui définit le comportement de ces actifs : la machine virtuelle Ethereum (EVM). Lors de l'évaluation de projets qui modifient l'EVM de leur propre réseau, l'équipe de sécurité de la blockchain de Coinbase examine les principaux changements EVM pour déterminer si l'EVM modifié peut fournir les mêmes garanties de sécurité et de garde que l'implémentation EVM d'origine.
État de la fourche EVM
Depuis mai 2023, la machine virtuelle Ethereum (EVM) a remporté le titre de "Big Brother" de la plateforme d'exécution de contrats intelligents la plus populaire. Selon DefiLlama, 9 des 10 principales chaînes de Total Value Locked (TVL) prennent en charge les contrats intelligents EVM. Par conséquent, une compréhension approfondie de l'EVM est essentielle pour prendre en charge les contrats intelligents dans l'ensemble de l'écosystème de la blockchain.
EVM est une machine virtuelle pour l'exécution décentralisée de contrats intelligents sur le réseau Ethereum. De nombreuses chaînes de blocs compatibles EVM exploitent les implémentations standard des clients d'implémentation Ethereum populaires dans différents langages tels que go-ethereum (Golang) et besu (Java) directement dans leur logiciel de protocole.
Cela dit, bifurquer et modifier l'EVM est en fait assez courant dans l'écosystème de la blockchain, même au sein des principaux protocoles. Par exemple, la pile Optimism Bedrock qui « alimente » la blockchain Base L2 de Coinbase utilise un fork du client d'exécution go-ethereum appelé op-geth, qui exécute le même EVM que le client d'exécution populaire ethereum compatible. Cependant, cela ne signifie pas que l'EVM sur Ethereum se comporte exactement de la même manière que l'EVM sur Optimism : l'EVM op-geth se comporte légèrement différemment dans certains cas (c'est-à-dire que la DIFFICULTÉ à renvoyer des valeurs aléatoires est déterminée par le séquenceur).
Bien que cela semble effrayant, cela est généralement bénéfique pour l'adoption de l'EVM. Alors que l'implémentation EVM standard est hautement optimisée pour le protocole de base Ethereum, les EVM bifurqués l'étendent souvent pour de nouveaux protocoles qui leur sont propres. Par conséquent, les contrats peuvent s'exécuter différemment sur certaines chaînes compatibles EVM que sur Ethereum, et les hypothèses de sécurité du comportement des contrats intelligents EVM peuvent également varier considérablement entre les différents protocoles.
Fork le cadre de sécurité EVM
À cette fin, Coinbase a développé un cadre de sécurité Web3 pour évaluer l'impact sur la sécurité de certaines implémentations EVM bifurquées. Nous l'appelons le framework EVM fourchu de Coinbase, qui sera expliqué en détail ci-dessous.
Avec ce framework de sécurité EVM fourchu, Coinbase est capable de :
Comprendre l'invalidité des hypothèses de sécurité de notre cadre de jetons Ethereum nous permet d'activer en toute sécurité de nouvelles chaînes de blocs compatibles EVM pour prendre en charge les jetons ERC-20/ERC-721 sur nos échanges décentralisés ;
Fournir aux auditeurs de contrats intelligents une analyse de la situation de vulnérabilité des contrats intelligents de l'EVM fourchue, en particulier les petites différences entre les réseaux ;
Garantissez l'utilisation et l'exécution en toute sécurité des contrats intelligents EVM sur la blockchain Base L2 de Coinbase.
Norme de sécurité pour les blockchains compatibles EVM
Afin de comprendre comment les risques de sécurité existent dans la machine virtuelle Ethereum, nous devons d'abord savoir quelles garanties nous apporte l'implémentation EVM standard. Nous définissons l'EVM standard comme l'EVM systématiquement utilisé par les clients d'exécution du validateur Ethereum, comme décrit dans la spécification d'implémentation Ethereum. Le client de loin le plus utilisé est go ethereum (c'est-à-dire geth).
Nous résumons la sécurité en deux critères de sécurité qui représentent les exigences minimales pour que toute implémentation EVM bifurquée soit éligible au support Coinbase.
Comment auditons-nous les risques de sécurité des implémentations EVM ?
Notre cadre EVM bifurqué se concentre sur les exigences d'audit suivantes lors de l'évaluation de la conformité aux critères de sécurité globaux (c'est-à-dire l'immuabilité du contrat et un environnement d'exécution sécurisé). Il convient de noter que les composants de risque suivants ne font pas partie de la portée complète de l'audit EVM de fourche.
La modification de la définition et de l'encodage des opcodes EVM peut entraîner des différences significatives dans la manière dont les contrats sont exécutés. Par exemple, supposons qu'une implémentation EVM bifurquée (EVM') modifie l'opcode arithmétique ADD pour définir la logique (x1 + x2) afin de soustraire deux valeurs (x1 - x2).
Il en résulte que l'EVM' dévié est inégal et incompatible dans son exécution avec l'EVM standard. Les conséquences de la modification des opcodes peuvent être un comportement bénéfique, tel que la prévention du débordement et du sous-dépassement d'entiers dans les opcodes arithmétiques, ou un comportement plus dangereux, tel qu'un comportement d'autodestruction qui provoque une frappe infinie d'actifs locaux.
EVM utilise des contrats précompilés pour définir des fonctions complexes (telles que des fonctions de chiffrement), en utilisant un langage plus pratique et performant tel que Golang, au lieu d'utiliser le bytecode EVM moins accessible.
Fondamentalement, il s'agit de fonctions programmées accessibles via des adresses de chaîne prédéterminées représentées dans le logiciel du nœud. Il y a 9 précompilateurs définis dans le livre jaune Ethereum (en date de mai 2023), et toute modification de ces 9 précompilateurs ou l'introduction de nouveaux précompilateurs doivent être auditées.
Prenons un autre exemple concret : la vulnérabilité BNB Smart Chain. La chaîne intelligente BNB utilise une implémentation déviée de go-ethereum pour exécuter des nœuds. À cette fin, deux nouveaux contrats pré-compilés (tmHeaderValidate, iavlMerkleProofValidate) sont introduits pour utiliser un logiciel tiers (c'est-à-dire Cosmos SDK) pour effectuer une validation de bloc client léger et une validation de preuve Merkle. Le problème est que le logiciel Cosmos SDK a un bogue d'implémentation dans sa représentation arborescente IAWL qui permet aux preuves cryptographiquement non valides de passer la vérification. En d'autres termes, n'importe qui peut générer de l'argent à partir de rien. Les attaquants ont pu exploiter cette faille d'implémentation imbriquée dans le précompilateur iavlMerkleProofValidate pour siphonner des centaines de millions de dollars du pont inter-chaînes Binance.
Cet exemple d'exploit est destiné à démontrer le besoin de sécurité du précompilateur et les risques potentiels d'introduction de nouveaux contrats précompilés pour des implémentations EVM déviantes.
Les risques potentiellement mortels liés à l'introduction de précompilateurs supplémentaires incluent :
Permettre à une partie de modifier unilatéralement l'état de tout contrat déployé ;
Cela inclut toutes les modifications de stockage (insertions, mises à jour, suppressions) ;
utilisation de dépendances tierces non approuvées, non vérifiées ou non auditées ;
Fournit l'accès à la valeur dans le nœud indéterminé.
Malgré le traitement du compilateur et de l'EVM comme des entités complètement distinctes, il convient de noter que le compilateur Solidity fait des hypothèses strictes sur le comportement des trois premiers contrats précompilés (ecrecover, sha256 et &ripemd) qui sont transmis via Solidity La fonction de mot-clé du langage natif représentation dans la langue. Dans les coulisses, le compilateur Solidity traite en fait ces mots-clés en bytecode, qui exécute des appels statiques entre les contrats. Le schéma ci-dessous illustre davantage cette manière de communiquer entre les contrats.
Les risques de sécurité introduits par la modification du précompilateur standard incluent :
Autoriser les contreparties centralisées à modifier unilatéralement l'état de tout contrat déployé ;
Cela inclut toutes les modifications de stockage (insertions, mises à jour, suppressions) ;
L'hypothèse de la position de précompilation du compilateur Solidity est incohérente ;
Fournit un accès aux valeurs dans des nœuds indéterminés ;
Utilisation de dépendances tierces non approuvées, non vérifiées ou non auditées.
Les principaux risques posés par la modification des composants fondamentaux de l'EVM incluent :
ne contraint pas la pile de l'interpréteur à être infiniment grande ;
Le redimensionnement ou la modification du modèle de mémoire peut entraîner une exécution non déterministe ;
Contourner le contrôle d'accès, permettant à toute contrepartie d'accéder unilatéralement à tous les états de la chaîne ;
Utilisation de dépendances tierces non approuvées, non vérifiées ou non auditées.
Pourquoi devrions-nous prêter attention à la sécurité EVM ?
Notre objectif est de construire un système financier ouvert basé sur la technologie blockchain, et à cette fin, nous encourageons le développement de diverses implémentations EVM. Cependant, pour qu'une blockchain conforme à l'EVM soit entièrement prise en charge par Coinbase, elle doit répondre aux exigences de base d'une implémentation EVM standard. Ce document espère sensibiliser aux risques associés à la déviation de l'EVM et encourager les émetteurs d'actifs à donner la priorité au développement de composants sécurisés lorsqu'ils s'écartent de l'EVM, sensibilisant ainsi l'ensemble de l'écosystème Web3 à la sécurité.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comment évaluer le risque de sécurité de "fork EVM" ?
Titre original : "Comment utiliser des EVM fourchues pour les risques de sécurité"
撰文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan
Compilateur : Katie Koo
Pour renforcer les garanties de sécurité et de garde pour les clients qui négocient ERC-20 et d'autres actifs basés sur des contrats intelligents, l'équipe Coinbase Blockchain Security a étudié la couche programmatique qui définit le comportement de ces actifs : la machine virtuelle Ethereum (EVM). Lors de l'évaluation de projets qui modifient l'EVM de leur propre réseau, l'équipe de sécurité de la blockchain de Coinbase examine les principaux changements EVM pour déterminer si l'EVM modifié peut fournir les mêmes garanties de sécurité et de garde que l'implémentation EVM d'origine.
État de la fourche EVM
Depuis mai 2023, la machine virtuelle Ethereum (EVM) a remporté le titre de "Big Brother" de la plateforme d'exécution de contrats intelligents la plus populaire. Selon DefiLlama, 9 des 10 principales chaînes de Total Value Locked (TVL) prennent en charge les contrats intelligents EVM. Par conséquent, une compréhension approfondie de l'EVM est essentielle pour prendre en charge les contrats intelligents dans l'ensemble de l'écosystème de la blockchain.
EVM est une machine virtuelle pour l'exécution décentralisée de contrats intelligents sur le réseau Ethereum. De nombreuses chaînes de blocs compatibles EVM exploitent les implémentations standard des clients d'implémentation Ethereum populaires dans différents langages tels que go-ethereum (Golang) et besu (Java) directement dans leur logiciel de protocole.
Cela dit, bifurquer et modifier l'EVM est en fait assez courant dans l'écosystème de la blockchain, même au sein des principaux protocoles. Par exemple, la pile Optimism Bedrock qui « alimente » la blockchain Base L2 de Coinbase utilise un fork du client d'exécution go-ethereum appelé op-geth, qui exécute le même EVM que le client d'exécution populaire ethereum compatible. Cependant, cela ne signifie pas que l'EVM sur Ethereum se comporte exactement de la même manière que l'EVM sur Optimism : l'EVM op-geth se comporte légèrement différemment dans certains cas (c'est-à-dire que la DIFFICULTÉ à renvoyer des valeurs aléatoires est déterminée par le séquenceur).
Bien que cela semble effrayant, cela est généralement bénéfique pour l'adoption de l'EVM. Alors que l'implémentation EVM standard est hautement optimisée pour le protocole de base Ethereum, les EVM bifurqués l'étendent souvent pour de nouveaux protocoles qui leur sont propres. Par conséquent, les contrats peuvent s'exécuter différemment sur certaines chaînes compatibles EVM que sur Ethereum, et les hypothèses de sécurité du comportement des contrats intelligents EVM peuvent également varier considérablement entre les différents protocoles.
Fork le cadre de sécurité EVM
À cette fin, Coinbase a développé un cadre de sécurité Web3 pour évaluer l'impact sur la sécurité de certaines implémentations EVM bifurquées. Nous l'appelons le framework EVM fourchu de Coinbase, qui sera expliqué en détail ci-dessous.
Avec ce framework de sécurité EVM fourchu, Coinbase est capable de :
Norme de sécurité pour les blockchains compatibles EVM
Afin de comprendre comment les risques de sécurité existent dans la machine virtuelle Ethereum, nous devons d'abord savoir quelles garanties nous apporte l'implémentation EVM standard. Nous définissons l'EVM standard comme l'EVM systématiquement utilisé par les clients d'exécution du validateur Ethereum, comme décrit dans la spécification d'implémentation Ethereum. Le client de loin le plus utilisé est go ethereum (c'est-à-dire geth).
Nous résumons la sécurité en deux critères de sécurité qui représentent les exigences minimales pour que toute implémentation EVM bifurquée soit éligible au support Coinbase.
Comment auditons-nous les risques de sécurité des implémentations EVM ?
Notre cadre EVM bifurqué se concentre sur les exigences d'audit suivantes lors de l'évaluation de la conformité aux critères de sécurité globaux (c'est-à-dire l'immuabilité du contrat et un environnement d'exécution sécurisé). Il convient de noter que les composants de risque suivants ne font pas partie de la portée complète de l'audit EVM de fourche.
La modification de la définition et de l'encodage des opcodes EVM peut entraîner des différences significatives dans la manière dont les contrats sont exécutés. Par exemple, supposons qu'une implémentation EVM bifurquée (EVM') modifie l'opcode arithmétique ADD pour définir la logique (x1 + x2) afin de soustraire deux valeurs (x1 - x2).
Il en résulte que l'EVM' dévié est inégal et incompatible dans son exécution avec l'EVM standard. Les conséquences de la modification des opcodes peuvent être un comportement bénéfique, tel que la prévention du débordement et du sous-dépassement d'entiers dans les opcodes arithmétiques, ou un comportement plus dangereux, tel qu'un comportement d'autodestruction qui provoque une frappe infinie d'actifs locaux.
EVM utilise des contrats précompilés pour définir des fonctions complexes (telles que des fonctions de chiffrement), en utilisant un langage plus pratique et performant tel que Golang, au lieu d'utiliser le bytecode EVM moins accessible.
Fondamentalement, il s'agit de fonctions programmées accessibles via des adresses de chaîne prédéterminées représentées dans le logiciel du nœud. Il y a 9 précompilateurs définis dans le livre jaune Ethereum (en date de mai 2023), et toute modification de ces 9 précompilateurs ou l'introduction de nouveaux précompilateurs doivent être auditées.
Prenons un autre exemple concret : la vulnérabilité BNB Smart Chain. La chaîne intelligente BNB utilise une implémentation déviée de go-ethereum pour exécuter des nœuds. À cette fin, deux nouveaux contrats pré-compilés (tmHeaderValidate, iavlMerkleProofValidate) sont introduits pour utiliser un logiciel tiers (c'est-à-dire Cosmos SDK) pour effectuer une validation de bloc client léger et une validation de preuve Merkle. Le problème est que le logiciel Cosmos SDK a un bogue d'implémentation dans sa représentation arborescente IAWL qui permet aux preuves cryptographiquement non valides de passer la vérification. En d'autres termes, n'importe qui peut générer de l'argent à partir de rien. Les attaquants ont pu exploiter cette faille d'implémentation imbriquée dans le précompilateur iavlMerkleProofValidate pour siphonner des centaines de millions de dollars du pont inter-chaînes Binance.
Cet exemple d'exploit est destiné à démontrer le besoin de sécurité du précompilateur et les risques potentiels d'introduction de nouveaux contrats précompilés pour des implémentations EVM déviantes.
Les risques potentiellement mortels liés à l'introduction de précompilateurs supplémentaires incluent :
Malgré le traitement du compilateur et de l'EVM comme des entités complètement distinctes, il convient de noter que le compilateur Solidity fait des hypothèses strictes sur le comportement des trois premiers contrats précompilés (ecrecover, sha256 et &ripemd) qui sont transmis via Solidity La fonction de mot-clé du langage natif représentation dans la langue. Dans les coulisses, le compilateur Solidity traite en fait ces mots-clés en bytecode, qui exécute des appels statiques entre les contrats. Le schéma ci-dessous illustre davantage cette manière de communiquer entre les contrats.
Les risques de sécurité introduits par la modification du précompilateur standard incluent :
Les principaux risques posés par la modification des composants fondamentaux de l'EVM incluent :
Pourquoi devrions-nous prêter attention à la sécurité EVM ?
Notre objectif est de construire un système financier ouvert basé sur la technologie blockchain, et à cette fin, nous encourageons le développement de diverses implémentations EVM. Cependant, pour qu'une blockchain conforme à l'EVM soit entièrement prise en charge par Coinbase, elle doit répondre aux exigences de base d'une implémentation EVM standard. Ce document espère sensibiliser aux risques associés à la déviation de l'EVM et encourager les émetteurs d'actifs à donner la priorité au développement de composants sécurisés lorsqu'ils s'écartent de l'EVM, sensibilisant ainsi l'ensemble de l'écosystème Web3 à la sécurité.