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, dont la fonction principale est de convertir le code source des langages de programmation de haut niveau en code d'instructions exécutable par le CPU ou la machine virtuelle de bas niveau.

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.

Prenons l'exemple d'un navigateur, durant le processus de compilation et d'exécution du code front-end JavaScript, il est possible qu'en raison d'une vulnérabilité dans le moteur d'analyse JavaScript, un utilisateur soit attaqué par un attaquant exploitant cette vulnérabilité lorsqu'il accède à une page web malveillante, permettant ainsi le contrôle à distance du navigateur de la victime, voire de son système d'exploitation. De plus, un bug dans le compilateur C++ peut également entraîner des conséquences graves telles que l'exécution de code à distance.

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, plusieurs versions du compilateur Solidity contiennent des vulnérabilités de sécurité.

Vulnérabilité du compilateur Solidity

Le 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 sont empaquetés dans des transactions et téléchargés sur Ethereum, où ils sont finalement interprétés et exécutés par l'EVM.

Il est important 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, pouvant affecter l'ensemble du réseau Ethereum. En revanche, les vulnérabilités du compilateur Solidity se réfèrent aux problèmes survenant lors de la conversion de Solidity en code EVM, et n'affectent pas directement le réseau Ethereum lui-même.

Une des menaces 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 de contrats intelligents. Étant donné que les contrats intelligents sur Ethereum sont généralement liés aux actifs cryptographiques des utilisateurs, tout bug 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 sur les problèmes de mise en œuvre de la logique du code de contrat, ainsi que sur des problèmes de sécurité au niveau de Solidity tels que la réentrée et le dépassement d'entier. Cependant, pour les vulnérabilités du compilateur Solidity, il est difficile de les détecter 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.

Exemples de vulnérabilités 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 les versions antérieures du compilateur Solidity (\u003e=0.1.6 \u003c0.4.4).

Considérez le code suivant :

solidité contrat C { uint32 a = 0x12345678; uint32 b = 0; fonction run() retourne (uint256) { a += 1; 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 le compilateur de la version vulnérable, run() retournera 1.

Cette situation inattendue, si la variable b est utilisée pour la vérification des autorisations, la comptabilité des actifs, etc., pourrait entraîner de graves conséquences.

La raison de cette situation est que l'EVM utilise des éléments de pile de taille 32 octets, tandis que Solidity prend en charge des types de données plus petits comme uint32. Le compilateur doit effectuer une opération de nettoyage sur les bits supérieurs lors du traitement de ces types, mais n'a pas géré correctement lors d'un dépassement d'entier, entraînant l'écriture d'un bit à 1 dans la variable b adjacente.

SOL-2022-4 Effets de mémoire InlineAssembly

Cette vulnérabilité existe dans les versions du compilateur de 0.8.13 à 0.8.15.

Considérez le code suivant :

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

Cette vulnérabilité provient des optimisations de compilation. Le compilateur analyse et optimise des blocs d'assembly individuels ; si une opération d'écriture en mémoire n'est pas suivie d'une lecture, elle sera supprimée pour économiser du gas. Cependant, l'écriture et la lecture en mémoire dans le code ci-dessus se trouvent dans deux blocs d'assembly différents, le compilateur détermine à tort que la première écriture est redondante et la supprime, ce qui entraîne que la fonction f() retourne 0 au lieu de 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(bytes4[] calldata a) externe pure retourne (bytes4[] mémoire) { return abi.decode(abi.encode(a), (bytes4[])); } }

Dans des conditions normales, ce code devrait retourner la variable a d'entrée. Mais dans la version vulnérable, si l'entrée est "aaaa", il renverra un tableau vide.

C'est parce que Solidity a mal nettoyé certaines données lors de l'opération abi.encode sur les tableaux de type calldata, ce qui a entraîné une modification des données adjacentes, provoquant une incohérence des données après encodage et décodage.

Il est à noter que Solidity encode implicitement les paramètres avec abi.encode lors d'appels externes et d'émission d'événements, donc la probabilité que de tels vulnérabilités se produisent peut être plus élevée qu'on ne le pense.

Conseils de sécurité

Concernant les vulnérabilités du compilateur Solidity, 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. Les nouvelles versions corrigent généralement des problèmes de sécurité connus.
• 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. En augmentant la couverture des tests, on peut éviter au maximum ce type de problèmes.
• Évitez autant que possible d'utiliser des assemblages en ligne, des opérations de décodage et d'encodage ABI complexes, et n'utilisez pas aveuglément de nouvelles fonctionnalités et des fonctionnalités expérimentales. La plupart des vulnérabilités des compilateurs sont liées à ces opérations complexes.

Pour le personnel de sécurité :

• Lors de l'audit du code Solidity, ne négligez pas les risques de sécurité que le compilateur peut introduire.
• Dans le processus de développement interne, incitez l'équipe de développement à mettre à jour la version du compilateur Solidity, envisagez d'introduire une vérification automatique de la version du compilateur dans le processus CI/CD.
• Ne vous inquiétez pas trop des vulnérabilités du compilateur, la plupart des vulnérabilités ne se déclenchent que dans des modèles de code spécifiques, et il est nécessaire d'évaluer l'impact réel en fonction des circonstances 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 compilateurs de chaque version
• Le point d'exclamation en triangle dans le coin supérieur droit de la page de code du contrat sur Etherscan peut indiquer les vulnérabilités de sécurité présentes dans la version actuelle du compilateur.

En résumé, les vulnérabilités du compilateur Solidity constituent un risque de sécurité non négligeable dans le développement de contrats intelligents. Les développeurs et les experts en sécurité doivent rester vigilants et prendre des mesures appropriées pour réduire les menaces potentielles posées par de telles vulnérabilités.