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

Le compilateur est l'un des éléments fondamentaux des systèmes informatiques modernes. C'est un programme informatique dont la fonction principale est de transformer le code source des langages de programmation de haut niveau, facilement compréhensibles et écrits par les humains, en instructions exécutables par le CPU ou la machine virtuelle bytecode.

La plupart des développeurs et des experts en sécurité se concentrent généralement sur la sécurité du code des applications, mais peuvent négliger les problèmes de sécurité du compilateur lui-même. En fait, le compilateur, en tant que programme informatique, présente également des vulnérabilités de sécurité, et ces vulnérabilités peuvent entraîner des risques de sécurité graves dans des situations spécifiques. Par exemple, lors de la compilation et de l'analyse du code front-end JavaScript par le navigateur, des vulnérabilités dans le moteur d'analyse JavaScript peuvent permettre aux attaquants d'exploiter des failles pour exécuter du code à distance lorsque les utilisateurs accèdent à des pages Web malveillantes, prenant finalement le contrôle du navigateur de la victime, voire de son système d'exploitation.

Le compilateur Solidity ne fait pas exception, selon les avertissements de sécurité de l'équipe de développement de Solidity, plusieurs versions différentes du compilateur Solidity présentent des vulnérabilités de sécurité.

Vulnérabilité du compilateur Solidity

Le rôle du compilateur Solidity est de convertir le code de contrat intelligent écrit par les développeurs en code d'instruction EVM( de la machine virtuelle Ethereum). Ces codes d'instruction EVM sont empaquetés dans des transactions et téléchargés sur Ethereum, 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 propres à l'EVM. 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. Étant donné que les attaquants peuvent télécharger n'importe quel code sur Ethereum, ce code sera finalement exécuté dans chaque programme client P2P Ethereum, et si l'EVM présente des vulnérabilités de sécurité, cela pourrait affecter l'ensemble du réseau Ethereum, entraînant potentiellement un déni de service (DoS) ou même un contrôle total par des attaquants. Cependant, en raison de la conception relativement simple de l'EVM et du fait que le code de base n'est pas fréquemment mis à jour, la probabilité de rencontrer les problèmes susmentionnés est relativement faible.

Les vulnérabilités du compilateur Solidity se réfèrent aux problèmes qui surviennent lorsque le compilateur convertit Solidity en code EVM. Contrairement aux scénarios où des langages comme JavaScript sont compilés et exécutés sur l'ordinateur client de l'utilisateur, le processus de compilation de Solidity se déroule uniquement sur l'ordinateur du développeur de contrat intelligent, sans exécution sur Ethereum. Par conséquent, les vulnérabilités du compilateur Solidity n'affectent pas le réseau Ethereum lui-même.

Une des principales dangers des vulnérabilités du compilateur Solidity réside dans le fait 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 cryptographiques des utilisateurs, tout bug dans un contrat intelligent causé par le compilateur pourrait entraîner des pertes d'actifs pour les utilisateurs, engendrant des conséquences graves.

Les développeurs et les auditeurs de contrats pourraient se concentrer sur les problèmes de mise en œuvre 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'entiers. En revanche, il est 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 le contrat intelligent est affecté par des vulnérabilités du compilateur.

Exemple de vulnérabilité du compilateur Solidity

Les exemples suivants de plusieurs cas réels de vulnérabilités des compilateurs Solidity montrent 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 = 0x1234; uint32 b = 0; fonction f() publique { a += 1; } fonction run() publique vue renvoie (uint32) { return b; } }

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

Si l'on ne comprend pas la vulnérabilité de ce compilateur, il est difficile pour un développeur ordinaire de détecter, par une simple révision de code, les bogues présents dans le code ci-dessus. C'est juste un exemple simple qui ne causera pas de conséquences particulièrement graves. Mais si la variable b est utilisée pour des vérifications de permissions, de comptabilité d'actifs, etc., cette incohérence par rapport aux attentes pourrait entraîner des problèmes très graves.

La raison de ce phénomène étrange réside dans le fait que l'EVM utilise une machine virtuelle à pile, où chaque élément de la pile fait 32 octets de taille (, c'est-à-dire la taille d'une variable uint256 ). D'autre part, chaque emplacement de stockage sous-jacent (storage) est également de 32 octets de taille. Le langage Solidity prend en charge des types de données plus petits que 32 octets, tels que uint32, et le compilateur doit effectuer des opérations de nettoyage appropriées sur les bits de poids fort de ces variables (clean up) pour assurer l'exactitude des données. Dans cette situation, lorsque l'addition entraîne un débordement d'entier, le compilateur ne nettoie pas correctement les bits de poids fort du résultat, ce qui entraîne l'écriture d'un bit de poids fort de 1 dans le stockage après le débordement, remplaçant ainsi la variable a par la variable b, modifiant la valeur de b à 1.

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

Considérez le code suivant :

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

Cette vulnérabilité existe dans les compilateurs des versions >=0.8.13 <0.8.15. 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, réalisant divers processus d'optimisation de compilation pour réduire la taille du code généré et optimiser la consommation de gas pendant le processus d'exécution. Ce type d'opération d'optimisation est courant dans les compilateurs de nombreux langages de haut niveau, mais en raison de la complexité des situations à considérer, il est également 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érations d'optimisation. Supposons qu'il existe un code dans une fonction qui modifie les données à l'adresse mémoire 0, mais qu'aucun endroit ultérieur n'utilise ces données, alors en fait, 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 des programmes ultérieurs.

Cette stratégie d'optimisation n'a pas de problème en soi, mais dans l'implémentation du code du compilateur Solidity, cette optimisation ne s'applique qu'à un seul bloc d'assembly. Dans le code PoC ci-dessus, l'écriture et l'accès à la mémoire 0 se trouvent dans deux blocs d'assembly différents, mais le compilateur n'a effectué une analyse d'optimisation que sur le bloc d'assembly séparé. É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, cette instruction d'écriture est considérée comme superflue et sera supprimée, ce qui entraîne un bug. Dans la version vulnérable, la fonction f() retournera la valeur 0, alors qu'en réalité, la valeur correcte que le code ci-dessus devrait retourner est 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Considérez le code suivant :

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

Cette vulnérabilité affecte les versions de compilateur >= 0.5.8 < 0.8.16. Normalement, la variable a retournée par le code ci-dessus devrait être "aaaa". Cependant, dans la version vulnérable, elle retourne une chaîne vide "".

La cause de cette vulnérabilité est que Solidity effectue une opération abi.encode sur des tableaux de type calldata, en nettoyant incorrectement certaines données, ce qui modifie d'autres données adjacentes, entraînant 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 d'appels externes et d'émission d'événements, ce qui rend la probabilité d'apparition du code de vulnérabilité ci-dessus plus élevée qu'on ne le pense intuitivement.

Conseils de sécurité

L'équipe de sécurité blockchain de Cobo, après avoir analysé le modèle de menace des vulnérabilités du compilateur Solidity et examiné les vulnérabilités historiques, propose les recommandations suivantes aux développeurs et aux responsables 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 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 qui ne correspondent pas aux attentes. Ce type de problème est difficile à détecter par l'examen du code, mais il est facile de le révéler lors de la phase de test. Par conséquent, en augmentant la couverture du code, on peut minimiser 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 caractéristiques du langage et les fonctionnalités expérimentales sans besoin clair juste pour impressionner. Selon l'analyse de l'équipe de sécurité de Cobo sur l'historique des vulnérabilités de Solidity, la plupart des vulnérabilités sont liées à l'assemblage en ligne, aux encodeurs ABI et d'autres opérations. Le compilateur a effectivement plus de chances 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 caractéristiques, conduisant à 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. 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, incitez l'équipe de développement à mettre à jour la version du compilateur Solidity, et envisagez d'introduire un contrôle automatique de la version du compilateur dans le processus CI/CD.

• Mais il n'est pas nécessaire de paniquer excessivement à 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 il n'est pas certain qu'il y ait un risque de sécurité simplement parce qu'un contrat a été compilé avec une version vulnérable du compilateur. L'impact réel sur la sécurité doit être évalué en fonction des spécificités du projet.

Ressources pratiques:

• Alertes de sécurité publiées régulièrement par l'équipe Solidity :

• Liste des bugs mise à jour régulièrement dans le repo officiel de Solidity :

• Liste des bugs des différents compilateurs :

• Sur Etherscan, le triangle avec un point d'exclamation dans le coin supérieur droit de la page Code du contrat peut indiquer les vulnérabilités de sécurité présentes dans la version actuelle du compilateur.

Résumé

Cet article commence par les concepts de base des compilateurs, présente les vulnérabilités du compilateur Solidity et analyse les risques de sécurité potentiels qu'elles pourraient entraîner dans un environnement de développement Ethereum réel. Enfin, il fournit aux développeurs et aux responsables de la sécurité plusieurs conseils pratiques en matière de sécurité.