Analyse des vulnérabilités du compilateur Solidity et stratégies d'atténuation

Un compilateur est l'un des composants fondamentaux des systèmes informatiques modernes. C'est un type de programme informatique spécial qui est responsable de la conversion du code source écrit dans un langage de programmation de haut niveau, facile à comprendre et à écrire pour les humains, en instructions que le CPU sous-jacent ou la machine virtuelle à bytecode peuvent exécuter.

Bien que la plupart des développeurs et des experts en sécurité se concentrent généralement davantage sur la sécurité du code des applications, la sécurité du compilateur lui-même ne doit pas être négligée. En tant que type de programme informatique, un compilateur peut également présenter des vulnérabilités de sécurité, qui dans certains cas peuvent entraîner de graves risques de sécurité. Par exemple, lors de la compilation et de l'analyse de l'exécution du code Javascript côté client, un bogue dans le moteur d'analyse Javascript peut permettre à un attaquant d'exploiter une vulnérabilité lors de l'accès à une page web malveillante, permettant ainsi l'exécution de code à distance et, en fin de compte, le contrôle du navigateur de la victime, voire de l'ensemble du système d'exploitation.

Le compilateur Solidity ne fait pas exception, il présente des vulnérabilités de sécurité dans plusieurs versions différentes.

Vulnérabilité du compilateur Solidity

Le principal objectif du compilateur Solidity est de convertir le code de contrat intelligent écrit par les développeurs en un code d'instructions exécutable par la machine virtuelle Ethereum (EVM). Ce code d'instructions EVM est empaqueté et téléchargé sur le réseau Ethereum via des transactions, et finalement interprété et exécuté par l'EVM.

Il est important de noter que les vulnérabilités du compilateur Solidity sont différentes de celles de l'EVM elle-même. Les vulnérabilités de l'EVM font référence aux problèmes de sécurité qui surviennent lorsque la machine virtuelle exécute des instructions. Étant donné que les attaquants peuvent télécharger n'importe quel code sur le réseau Ethereum, ce code finira par s'exécuter dans chaque programme client P2P d'Ethereum. Si l'EVM présente des vulnérabilités de sécurité, cela peut affecter l'ensemble du réseau Ethereum, entraînant un déni de service (DoS) ou même permettant à un attaquant de contrôler l'ensemble de la blockchain. Cependant, en raison de la conception relativement simple de l'EVM et du fait que le code de base n'est pas souvent mis à jour, la probabilité de tels problèmes est relativement faible.

Les vulnérabilités du compilateur Solidity font référence aux problèmes rencontrés 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 l'ordinateur client de l'utilisateur, le processus de compilation de Solidity n'a lieu que sur l'ordinateur du développeur de contrats intelligents et n'est pas exécuté sur le réseau Ethereum. Par conséquent, les vulnérabilités du compilateur Solidity n'affectent pas directement le réseau Ethereum lui-même.

Une des principales dangers des vulnérabilités des compilateurs Solidity est qu'elles peuvent entraîner une génération de code EVM qui ne correspond pas aux attentes des développeurs de contrats intelligents. Étant donné que les contrats intelligents sur Ethereum impliquent souvent des actifs de cryptomonnaie des utilisateurs, tout bug de contrat intelligent causé par le compilateur peut entraîner des pertes d'actifs pour les utilisateurs, entraînant des conséquences graves.

Les développeurs et les auditeurs de contrats peuvent se concentrer sur les problèmes de mise en œuvre de la logique du code de contrat, ainsi que sur les problèmes de sécurité au niveau de Solidity tels que les réentrées et les débordements d'entiers. Cependant, il est difficile de découvrir les vulnérabilités du compilateur Solidity simplement en auditant la logique du code source du contrat. Il est nécessaire d'analyser en combinaison une version de compilateur spécifique et des modèles de code spécifiques pour déterminer si un contrat intelligent est affecté par des vulnérabilités du compilateur.

Exemples de vulnérabilités du compilateur Solidity

Voici quelques exemples réels de vulnérabilités du compilateur Solidity, montrant leurs formes, causes et dangers spécifiques.

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 :

solidity contrat C { uint32 a = 0x1234; uint32 b = 0; fonction f() publique { a += 1; } fonction run() public view returns (uint) { return b; } }

La variable de stockage b n'a subi aucune modification, donc la fonction run() devrait retourner la valeur par défaut 0. Cependant, dans le code généré par la version vulnérable du compilateur, run() retourne en réalité 1.

Il est difficile pour un développeur ordinaire de détecter les problèmes présents dans le code ci-dessus simplement par une révision de code. Bien que cet exemple soit relativement simple et ne cause peut-être pas de conséquences particulièrement graves, si la variable b est utilisée pour des usages critiques comme la validation des autorisations ou la comptabilité des actifs, ce type de situation inattendue pourrait entraîner de graves vulnérabilités de sécurité.

La racine de ce problème réside dans le fait que l'EVM utilise une machine virtuelle à pile, où chaque élément de la pile fait 32 octets (c'est-à-dire la taille d'une variable uint256). Chaque slot de stockage au niveau inférieur fait également 32 octets. Le langage Solidity prend en charge des types de données tels que uint32 et d'autres de moins de 32 octets. Lorsque le compilateur traite ces types de variables, il doit effectuer des opérations de nettoyage appropriées sur les bits de poids élevé pour garantir l'exactitude des données. Dans la situation décrite, lorsque l'addition entraîne un débordement entier, le compilateur n'a pas correctement nettoyé les bits de poids élevé du résultat, ce qui a conduit à l'écriture d'un bit de 1 de poids élevé dans le stockage après le débordement, recouvrant finalement la variable a et modifiant la valeur de la variable b à 1.

SOL-2022-4 Effets de mémoire en assemblage en ligne

Cette vulnérabilité existe dans les compilateurs de version >=0.8.13 <0.8.15. Considérez le code suivant :

solidity contrat C { fonction f() public pure retourne (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. Il effectue également une analyse approfondie du flux de contrôle et des données, mettant en œuvre divers processus d'optimisation de compilation pour réduire la taille du code généré et optimiser la consommation de gas pendant l'exécution. Ce type d'opération d'optimisation est courant dans les compilateurs de divers langages de haut niveau, mais en raison de la complexité des situations à considérer, il est également susceptible de provoquer des bugs ou des vulnérabilités de sécurité.

La vulnérabilité du code mentionné provient de ce type d'opérations d'optimisation. Le compilateur considère que si un certain code modifie les données à l'offset 0 de la mémoire, mais qu'aucun autre endroit n'utilise ces données par la suite, alors il peut directement supprimer le code de modification de la mémoire 0, économisant ainsi du gas, tout en n'affectant pas la logique du programme par la suite.

Cette stratégie d'optimisation n'est pas en soi problématique, mais dans l'implémentation spécifique du code du compilateur Solidity, ce type d'optimisation n'est appliqué qu'à un seul bloc d'assembly. Dans le code PoC mentionné ci-dessus, l'écriture et l'accès à la mémoire 0 se trouvent dans deux blocs d'assembly différents, tandis que le compilateur n'a analysé et optimisé qu'un seul bloc d'assembly. Étant donné qu'il n'y a aucune opération de lecture après l'écriture de la mémoire 0 dans le premier bloc d'assembly, cette instruction d'écriture est jugée redondante et sera supprimée, ce qui entraîne un bug. Dans la version vulnérable, la fonction f( renverra la valeur 0, alors qu'en réalité, la valeur correcte que ce code devrait renvoyer est 0x42.

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Cette vulnérabilité affecte les compilateurs des versions >= 0.5.8 < 0.8.16. Considérez le code suivant :

solidité contrat C { fonction f###string( calldata a[1] externe pure retourne )string mémoire( { return abi.decode)abi.encode(a(, )string([1])); } }

En règle générale, 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 un tableau de type calldata, en nettoyant incorrectement certaines données, ce qui modifie d'autres données adjacentes et entraîne une incohérence des données après encodage et décodage.

Il est important de noter que Solidity effectue implicitement un abi.encode sur les paramètres lors des appels externes et de l'émission d'événements, ce qui signifie que la probabilité d'apparition du code de vulnérabilité mentionné est plus élevée qu'on ne pourrait le 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é

Après avoir analysé le modèle de menace des vulnérabilités du compilateur Solidity et examiné les vulnérabilités historiques, nous proposons les recommandations suivantes aux développeurs et aux experts en sécurité.

) Pour les développeurs :

1. Utilisez une version plus récente du compilateur Solidity. Bien que les nouvelles versions puissent également introduire de nouveaux problèmes de sécurité, les problèmes de sécurité connus sont généralement moins nombreux que ceux des anciennes versions.

2. 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 qui ne correspondent pas aux attentes. Ce type de problème est difficile à détecter par la révision du code, mais il est facilement exposé lors de la phase de test. Par conséquent, en augmentant la couverture du code, on peut éviter au maximum ce type de problème.

3. Essayez d'éviter d'utiliser l'assemblage en ligne, le codage et le décodage ABI pour des tableaux multidimensionnels et des structures complexes, et évitez d'utiliser aveuglément de nouvelles fonctionnalités du langage et des fonctionnalités expérimentales sans nécessité explicite. D'après l'analyse des vulnérabilités historiques, la plupart des vulnérabilités sont liées à des opérations telles que l'assemblage en ligne et les encodeurs ABI. Les compilateurs sont plus susceptibles de rencontrer des bogues lorsqu'ils traitent des caractéristiques complexes du langage. D'autre part, les développeurs peuvent également se tromper dans l'utilisation de nouvelles fonctionnalités, ce qui entraîne des problèmes de sécurité.

Aux agents de sécurité :

1. Lors de l'audit de sécurité du code Solidity, ne négligez pas les risques de sécurité que le compilateur Solidity 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.

2. Dans le processus de développement interne SDL, exhorter 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.

3. Cependant, il n'est pas nécessaire de paniquer excessivement à propos des vulnérabilités des compilateurs, car la plupart des vulnérabilités ne se déclenchent que dans des modèles de code spécifiques. Il n'est pas garanti qu'un contrat compilé avec une version vulnérable du compilateur présente 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.

Ressources pratiques

• Articles d'alerte de sécurité publiés régulièrement par l'équipe Solidity
• Liste des bugs mise à jour régulièrement dans le dépôt officiel de Solidity
• Liste des bugs des différentes versions du compilateur. Cela peut être utilisé pour introduire une vérification automatique de la version du compilateur dans le processus CI/CD, en signalant les vulnérabilités de sécurité présentes dans la version actuelle.
• Sur Etherscan, l'icône en forme de triangle avec un point d'exclamation dans le coin supérieur droit de la page Code du contrat peut indiquer les failles de sécurité existantes dans la version actuelle du compilateur.

![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, et analyse les risques de sécurité qu'elles peuvent engendrer dans un environnement de développement Ethereum réel. Enfin, il fournit aux développeurs et aux professionnels de la sécurité plusieurs conseils pratiques de sécurité. En comprenant ces vulnérabilités et en prenant des mesures préventives appropriées, nous pouvons mieux protéger la sécurité des contrats intelligents et réduire les risques potentiels de perte d'actifs.