Analyse des vulnérabilités du compilateur Solidity et stratégies de réponse

Un compilateur est l'un des composants de base 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, facile à comprendre et à écrire pour les humains, en instructions exécutables par le CPU ou la machine virtuelle à code binaire.

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, mais ils peuvent négliger la sécurité du compilateur lui-même. En fait, en tant que programme informatique, le compilateur présente également des vulnérabilités de sécurité, et ces vulnérabilités peuvent, dans certaines situations, entraîner des risques de sécurité graves. Par exemple, lors du processus de compilation et d'analyse de l'exécution du code Javascript côté client, des vulnérabilités du moteur d'analyse Javascript peuvent permettre à un attaquant d'exploiter une faille lorsque l'utilisateur accède à une page web malveillante, aboutissant finalement à un contrôle du navigateur de la victime, voire de son 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és du compilateur Solidity

Le rôle du compilateur Solidity est de convertir le code des contrats intelligents écrit par les développeurs en code d'instructions (EVM) pour la machine virtuelle Ethereum, ces codes d'instructions EVM étant empaquetés et téléchargés sur Ethereum par le biais de transactions, pour être finalement analysés et exécutés par l'EVM.

Il est nécessaire de distinguer les vulnérabilités du compilateur Solidity des vulnérabilités de l'EVM elle-même. Les vulnérabilités de l'EVM font référence aux problèmes de sécurité qui se produisent lorsque la machine virtuelle exécute des instructions. Étant donné que les attaquants peuvent télécharger n'importe quel code sur 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 affectera l'ensemble du réseau Ethereum et pourrait entraîner un déni de service (DoS), voire permettre à un attaquant de prendre complètement le contrôle de la chaîne. Cependant, en raison de la conception relativement simple de l'EVM et du fait que le code central n'est pas fréquemment mis à jour, la probabilité de problèmes susmentionnés est relativement faible.

Les vulnérabilités du compilateur Solidity font référence aux problèmes survenant lorsque le compilateur convertit Solidity en code EVM. Contrairement à un navigateur qui compile et exécute Javascript sur l'ordinateur client de l'utilisateur, le processus de compilation de Solidity se déroule uniquement sur l'ordinateur du développeur de contrats intelligents et ne s'exécute pas sur 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 menaces liées aux vulnérabilités des compilateurs Solidity est qu'elles peuvent entraîner une incohérence entre le code EVM généré et les attentes des développeurs de contrats intelligents. Étant donné que les contrats intelligents sur Ethereum impliquent souvent les actifs en cryptomonnaie des utilisateurs, tout bug de contrat intelligent causé par le compilateur pourrait 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 sur les problèmes d'implémentation logique du code des contrats, ainsi que sur les problèmes de sécurité au niveau de Solidity tels que la réentrance et le dépassement d'entier. Cependant, il est très difficile de détecter les vulnérabilités du compilateur Solidity uniquement par l'audit de la logique du code source du contrat. Il est nécessaire d'analyser conjointement des versions spécifiques du compilateur et des modèles de code spécifiques pour déterminer si un contrat intelligent est affecté par des vulnérabilités du compilateur.

Exemple de vulnérabilité du compilateur Solidity

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

SOL-2016-9 HighOrderByteCleanStorage

Cette vulnérabilité existe dans des versions antérieures du compilateur Solidity (>=0.1.6 <0.4.4).

Considérez le code suivant :

solidité contrat C { uint32 a = 0x1234; uint32 b = 0; fonction f() public { a += 1; } fonction run() public view retourne (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. Mais en réalité, dans le code généré par une version de compilateur vulnérable, run() va retourner 1.

Sans comprendre la vulnérabilité du compilateur, il est difficile pour un développeur ordinaire de détecter le bug présent dans le code ci-dessus par une simple révision de code. Cet exemple de code est relativement simple et peut ne pas causer de dommages particulièrement graves. Mais si la variable b est utilisée pour des vérifications d'autorisation, la comptabilité des actifs, etc., cette incohérence par rapport aux attentes pourrait entraîner des conséquences très graves.

La raison de cette anomalie est que l'EVM utilise une machine virtuelle à pile, chaque élément de la pile étant de 32 octets, c'est-à-dire la taille d'une variable uint256, (. D'autre part, chaque slot de stockage sous-jacent est également de 32 octets. Cependant, le langage Solidity prend en charge des types de données de moins de 32 octets, comme uint32. Lorsque le compilateur traite ce type de variable, il doit effectuer des opérations de nettoyage appropriées sur ses bits les plus significatifs, )clean up(, pour garantir l'intégrité des données. Dans le cas mentionné ci-dessus, lors d'un débordement d'entier lors d'une addition, le compilateur n'a pas correctement nettoyé les bits les plus significatifs du résultat, ce qui a entraîné l'écriture d'un bit de 1 dans le stockage après le débordement, écrasant finalement la variable a qui se trouve après la variable b, modifiant ainsi la valeur de b à 1.

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

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

solidité contrat C { fonction f###( publique pure retourne )uint( { assemblage { mstore)0, 0x42( } uint x; assemblage { x := mload)0( } return x; } }

Le compilateur Solidity ne se contente pas de traduire le langage Solidity en code EVM. 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 durant le processus d'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 cas à considérer, il est également facile de rencontrer des bogues ou des vulnérabilités de sécurité.

La vulnérabilité dans le code mentionné provient de ce type d'opération d'optimisation. Considérons un scénario où un code modifie les données à l'adresse mémoire 0, mais qu'aucune autre partie du programme n'utilise ces données par la suite. En réalité, il est possible de supprimer directement le code qui modifie la mémoire 0, ce qui permet d'économiser du gas sans affecter la logique du programme ultérieure.

Cette stratégie d'optimisation n'est pas problématique en soi, mais dans l'implémentation concrète du code du compilateur Solidity, ce type d'optimisation n'est appliqué qu'à l'intérieur d'un seul bloc d'assembly. Dans le code d'exemple 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é que le bloc d'assembly unique. Étant donné qu'il n'y a aucune opération de lecture après l'écriture dans la mémoire 0 dans le premier bloc d'assembly, l'instruction d'écriture est considérée comme redondante et sera supprimée, ce qui entraînera un bug. Dans la version contenant la vulnérabilité, la fonction f) renverra la valeur 0, alors qu'en réalité, le code ci-dessus devrait retourner la valeur correcte 0x42.

( SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Cette vulnérabilité affecte les compilateurs de la version >= 0.5.8 et < 0.8.16. Considérez le code suivant :

solidité contrat C { fonction f)uint8### calldata a( public pure returns [4]string mémoire) { return string(abi.encode)a((; } }

En règle générale, la variable a renvoyée par le code ci-dessus devrait être "aaaa". Cependant, dans la version contenant la vulnérabilité, elle renverra une chaîne vide "".

La cause de cette vulnérabilité est que Solidity, lors de l'opération abi.encode sur un tableau de type calldata, a incorrectement nettoyé certaines données, entraînant la modification d'autres données adjacentes, ce qui a entraîné une incohérence dans les données après encodage et décodage.

Il est à noter que Solidity effectue implicitement un abi.encode sur les paramètres lors des appels externes et de l'émission d'événements, de sorte que la probabilité d'apparition du code de vulnérabilité ci-dessus est plus élevée qu'on ne le pense intuitivement.

![Analyse des vulnérabilités du compilateur Solidity et mesures de réponse])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp)

Conseils de sécurité

Sur la base de l'analyse du modèle de menace des vulnérabilités du compilateur Solidity et de l'examen des vulnérabilités historiques, les recommandations suivantes sont proposées aux développeurs et aux professionnels de la sécurité.

Pour les développeurs:

• 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 versions plus anciennes.

• 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 de code, mais il est facilement révélé lors de la phase de test. Ainsi, en augmentant la couverture du code, on peut éviter au maximum ce type de problème.

• Évitez autant que possible d'utiliser l'assemblage en ligne, le décodage et l'encodage ABI pour des tableaux multidimensionnels et des structures complexes, et évitez d'utiliser aveuglément les nouvelles fonctionnalités et les fonctionnalités expérimentales du langage sans besoin clair. D'après l'analyse des vulnérabilités historiques, la plupart des vulnérabilités sont liées à l'assemblage en ligne et aux encodeurs ABI. Les compilateurs ont effectivement plus de chances de rencontrer des bugs lorsqu'ils traitent des caractéristiques complexes du langage. D'autre part, les développeurs peuvent également rencontrer des malentendus lors de l'utilisation de nouvelles fonctionnalités, entraînant 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 Solidity pourrait introduire. Dans la classification des faiblesses des contrats intelligents ( SWC ), l'élément de vérification correspondant est SWC-102 : Version du compilateur obsolète.

• Dans le processus de développement interne de SDL, incitez l'équipe de développement à mettre à jour la version du compilateur Solidity, et envisagez d'introduire une vérification automatique de la version du compilateur dans le processus CI/CD.

• Cependant, il ne faut pas trop paniquer à propos des vulnérabilités des compilateurs ; la plupart des vulnérabilités de compilateurs ne se déclenchent que dans des modèles de code spécifiques. Utiliser une version vulnérable d'un compilateur pour compiler un contrat ne signifie pas nécessairement qu'il y a un risque de sécurité. L'impact réel sur la sécurité doit être évalué en fonction de la situation du projet.

Quelques ressources utiles :

• Alertes de sécurité publiées 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 :

• Sur Etherscan, le symbole d'exclamation en triangle dans le coin supérieur droit de la page Code du contrat peut indiquer les vulnérabilités de sécurité associées à la version actuelle du compilateur.

Résumé

Cet article commence par les concepts de base des compilateurs, introduit les vulnérabilités des compilateurs Solidity et analyse les risques de sécurité qu'elles peuvent entraîner dans un environnement de développement Ethereum réel, et fournit enfin plusieurs conseils pratiques en matière de sécurité pour les développeurs et les professionnels de la sécurité.