- Rubrique
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
- Épingler
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
Analyse des vulnérabilités du compilateur Solidity et stratégies de réponse
Détails sur les vulnérabilités du compilateur Solidity et stratégies de réponse
Un compilateur est l'un des composants fondamentaux des systèmes informatiques modernes. C'est un programme informatique dont la fonction principale est de convertir le code source écrit dans un langage de programmation de haut niveau en code d'instructions exécutable par le CPU ou la machine virtuelle sous-jacente.
Bien que la plupart des développeurs et des professionnels de la sécurité se concentrent généralement sur la sécurité du code des applications, la sécurité du compilateur lui-même est tout aussi importante. En tant que programme informatique, un compilateur peut également présenter des vulnérabilités de sécurité, ce qui peut, dans certains cas, entraîner des risques de sécurité graves. Par exemple, lors de la compilation et de l'analyse du code JavaScript côté client, un navigateur peut être exploité par des attaquants en raison de vulnérabilités dans le moteur d'analyse JavaScript, permettant ainsi à ces derniers de prendre le contrôle du navigateur de la victime, voire de son système d'exploitation.
Le compilateur Solidity présente également des vulnérabilités de sécurité. Selon les avertissements de sécurité de l'équipe de développement de Solidity, des problèmes de sécurité ont été découverts dans plusieurs versions différentes du compilateur Solidity.
Vulnérabilité du compilateur Solidity
Le principal rôle du compilateur Solidity est de convertir le code des contrats intelligents en code d'instructions EVM( pour la machine virtuelle Ethereum). Ces codes d'instructions EVM sont empaquetés et téléchargés sur Ethereum par le biais de transactions, et finalement analysés et exécutés par l'EVM.
Il convient de noter que les vulnérabilités du compilateur Solidity sont différentes des vulnérabilités de l'EVM elle-même. Les vulnérabilités de l'EVM se réfèrent aux problèmes de sécurité qui surviennent lorsque la machine virtuelle exécute des instructions. Comme les attaquants peuvent télécharger n'importe quel code sur Ethereum, si l'EVM présente des vulnérabilités de sécurité, cela affectera l'ensemble du réseau Ethereum, pouvant entraîner un déni de service (DoS) voire la prise de contrôle de l'ensemble de la blockchain par les attaquants. Cependant, la conception de l'EVM est relativement simple, les mises à jour du code de base ne sont pas fréquentes, ce qui réduit donc la probabilité de tels problèmes.
Les vulnérabilités du compilateur Solidity font référence aux problèmes survenant lors de la conversion du code Solidity en code EVM par le compilateur. Contrairement à la situation où un navigateur compile et exécute JavaScript sur le client de l'utilisateur, le processus de compilation de Solidity s'effectue uniquement sur l'ordinateur du développeur de contrats intelligents et n'est pas exécuté sur Ethereum. Par conséquent, les vulnérabilités du compilateur Solidity n'affectent pas directement le réseau Ethereum lui-même.
Un des principaux dangers des vulnérabilités du compilateur Solidity est qu'elles peuvent entraîner une incohérence entre le code EVM généré et les attentes des développeurs. Étant donné que les contrats intelligents sur Ethereum impliquent souvent les actifs en cryptomonnaie des utilisateurs, tout bug de contrat causé par le compilateur peut entraîner des pertes d'actifs pour les utilisateurs, avec des conséquences graves.
Les développeurs et les auditeurs de contrats peuvent se concentrer principalement sur les problèmes d'implémentation de la logique du code de contrat, ainsi que sur des problèmes de sécurité liés à Solidity tels que la réentrée et le débordement d'entiers. Cependant, les vulnérabilités des compilateurs sont souvent difficiles à détecter simplement en auditant le code source du contrat. Il est nécessaire de combiner des versions de compilateurs spécifiques et des modèles de code particuliers pour analyser et déterminer si le contrat intelligent est affecté par des vulnérabilités de compilateur.
Exemple de vulnérabilité du compilateur Solidity
Voici quelques exemples réels de vulnérabilités du compilateur Solidity, montrant leurs formes spécifiques, leurs causes et leurs dangers.
SOL-2016-9 HighOrderByteCleanStorage
Cette vulnérabilité existe dans les versions antérieures du compilateur Solidity (>=0.1.6 <0.4.4).
Considérez le code suivant :
solidité contrat C { uint32 a = 0x12345678; uint32 b = 0; fonction f() publique { a = a + 1; } fonction run() public view returns (uint) { return b; } }
La variable de stockage b n'a pas été modifiée, donc la fonction run() devrait retourner la valeur par défaut 0. Cependant, dans le code généré par le compilateur de la version vulnérable, run() retourne 1.
Sans comprendre la vulnérabilité de ce compilateur, il est difficile pour un développeur ordinaire de détecter ce bug par une simple révision de code. Bien que cet exemple soit relativement simple et ne cause pas de conséquences particulièrement graves, si la variable b est utilisée pour la vérification des autorisations, la comptabilité des actifs, etc., cette incohérence par rapport aux attentes pourrait entraîner des conséquences très graves.
La raison de ce phénomène réside dans le fait que l'EVM utilise une machine virtuelle basée sur une pile, chaque élément de la pile ayant une taille de 32 octets (, soit la taille d'une variable uint256 ). D'autre part, chaque emplacement de stockage sous-jacent (storage) a également une taille de 32 octets. Le langage Solidity prend en charge des types de données inférieurs à 32 octets, tels que uint32, et le compilateur doit effectuer des opérations de nettoyage appropriées sur les bits supérieurs lors du traitement de ces types (clean up) afin d'assurer l'intégrité des données. Dans le cas mentionné ci-dessus, lorsque l'addition entraîne un débordement d'entier, le compilateur n'a pas correctement nettoyé les bits supérieurs du résultat, ce qui a entraîné l'écriture d'un bit de 1 en position élevée dans le stockage, écrasant finalement la variable a et modifiant la valeur de la variable b à 1.
SOL-2022-4 InlineAssemblyMemorySideEffects
Cette vulnérabilité existe dans les compilateurs de version >=0.8.13 <0.8.15.
Considérez le code suivant :
solidité contrat C { fonction f() publique pure renvoie (uint) { assemblage { mstore(0, 0x42) } uint x; assemblage { x := mload(0) } return x; } }
Le compilateur Solidity, lors de la conversion du langage Solidity en code EVM, ne se contente pas d'une simple traduction, mais effectue également une analyse approfondie des flux de contrôle et des données, réalisant diverses optimisations de compilation pour réduire la taille du code généré et optimiser la consommation de gaz pendant le processus d'exécution. Ce type d'optimisation est courant dans les compilateurs de divers langages de haut niveau, mais en raison de la complexité des cas à considérer, il est facile d'introduire des bugs ou des vulnérabilités de sécurité.
La vulnérabilité du code ci-dessus provient de ce type d'opération d'optimisation. Si une fonction contient du code qui modifie les données à l'emplacement mémoire 0, mais que ces données ne sont pas utilisées par la suite, il est alors possible de supprimer directement le code de modification de la mémoire 0, ce qui permet d'économiser du gas sans affecter la logique du programme par la suite.
Cette stratégie d'optimisation n'est pas problématique en soi, mais dans l'implémentation concrète des compilateurs Solidity, ce type d'optimisation n'est appliqué qu'à un seul bloc assembly. Pour le code PoC mentionné ci-dessus, l'écriture et l'accès à la mémoire 0 se trouvent dans deux blocs assembly différents, et le compilateur n'a analysé et optimisé que le bloc assembly séparé. Comme il n'y a aucune opération de lecture après l'écriture de la mémoire 0 dans le premier bloc assembly, il détermine que cette instruction d'écriture est redondante et l'élimine, ce qui engendre un bug. Dans la version vulnérable, la fonction f( renverra la valeur 0, alors que la valeur de retour correcte devrait être 0x42.
) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Cette vulnérabilité affecte les compilateurs version >= 0.5.8 < 0.8.16.
Considérez le code suivant :
solidité contrat C { fonction f###string( calldata a[1] public pure returns )string mémoire( { return abi.decode)abi.encode(a(, )string([1])); } }
Dans des conditions normales, la variable a retournée par le code ci-dessus devrait être "aaaa". Cependant, dans la version vulnérable, elle renverra une chaîne vide "".
La cause de cette vulnérabilité est que Solidity effectue une opération abi.encode sur les tableaux de type calldata, nettoyant incorrectement certaines données, ce qui entraîne la modification d'autres données adjacentes et provoque une incohérence des données après encodage et décodage.
Il est important de noter que Solidity effectue implicitement une abi.encode sur les paramètres lors d'appels externes et d'émissions d'événements, ce qui rend la probabilité d'apparition du code de vulnérabilité mentionné plus élevée que ce que l'on pourrait intuitivement penser.
![Analyse des vulnérabilités du compilateur Solidity et mesures d'atténuation][0]https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Conseils de sécurité
Pour les menaces liées aux vulnérabilités du compilateur Solidity, voici les recommandations pour les développeurs et les experts en sécurité :
Pour les développeurs:
Utilisez une version plus récente du compilateur Solidity. Bien que les nouvelles versions puissent introduire de nouveaux problèmes de sécurité, les problèmes de sécurité connus sont généralement moins nombreux dans les anciennes versions.
Améliorer les cas de test unitaire. La plupart des bugs au niveau du compilateur entraînent des résultats d'exécution du code différents de ceux attendus. Ce type de problème est difficile à détecter par une révision de code, mais il est facilement révélé lors de la phase de test. Augmenter la couverture des tests peut éviter au maximum ce type de problème.
Évitez autant que possible d'utiliser de l'assemblage en ligne, des opérations complexes telles que le codage et le décodage abi pour des tableaux multidimensionnels et des structures complexes ; évitez d'utiliser aveuglément les nouvelles fonctionnalités et les fonctions expérimentales du langage sans besoin explicite. La plupart des vulnérabilités historiques sont liées à des opérations telles que l'assemblage en ligne et les encodeurs abi. Le compilateur est plus susceptible de rencontrer des bugs lorsqu'il traite des caractéristiques complexes du langage. D'autre part, les développeurs peuvent également faire des erreurs d'utilisation lors de l'utilisation de nouvelles fonctionnalités, ce qui peut entraîner des problèmes de sécurité.
Pour le personnel de sécurité :
Lors de l'audit de sécurité du code Solidity, ne négligez pas les risques de sécurité que le compilateur pourrait introduire. L'élément de vérification correspondant dans la classification des faiblesses des contrats intelligents )SWC( est SWC-102 : Version du compilateur obsolète.
Dans le processus de développement interne de SDL, encourager l'équipe de développement à mettre à jour la version du compilateur Solidity, et envisager d'introduire une vérification automatique de la version du compilateur dans le processus CI/CD.
Mais il ne faut pas trop paniquer à propos des vulnérabilités des compilateurs, la plupart des vulnérabilités des compilateurs ne se déclenchent que dans des modèles de code spécifiques, et cela ne signifie pas qu'un contrat compilé avec une version vulnérable du compilateur présente nécessairement un risque de sécurité. L'impact réel sur la sécurité doit être évalué spécifiquement en fonction de la situation du projet.
Quelques ressources utiles :
![Analyse des vulnérabilités du compilateur Solidity et mesures de réponse])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
Résumé
Cet article part des concepts de base des compilateurs pour introduire les vulnérabilités du compilateur Solidity, analyser les risques de sécurité qu'elles peuvent engendrer dans un environnement de développement Ethereum réel, et fournir aux développeurs et aux responsables de la sécurité quelques conseils pratiques en matière de sécurité. En comprenant et en accordant de l'importance aux vulnérabilités des compilateurs, il est possible d'assurer de manière plus complète la sécurité des contrats intelligents.