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

Le compilateur est l'un des composants de base des systèmes informatiques modernes. C'est un programme qui convertit les langages de programmation de haut niveau en instructions exécutables par l'ordinateur. Bien que les développeurs et les experts en 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.

Les compilateurs, en tant que programmes informatiques, peuvent également présenter des vulnérabilités de sécurité, ce qui peut entraîner de graves risques de sécurité dans certains cas. Par exemple, lors de l'analyse et de l'exécution de code JavaScript, un navigateur peut être attaqué en raison de vulnérabilités dans le moteur JavaScript, ce qui peut finalement conduire à ce que l'attaquant prenne 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 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 pour la machine virtuelle Ethereum (EVM). Ces instructions EVM sont empaquetées et téléchargées sur Ethereum par le biais de transactions, et finalement exécutées par l'EVM.

Il est nécessaire de distinguer les vulnérabilités du compilateur Solidity et les vulnérabilités de l'EVM elle-même. Les vulnérabilités de l'EVM se réfèrent à des failles de sécurité lors de l'exécution des instructions par la machine virtuelle, qui peuvent affecter l'ensemble du réseau Ethereum. En revanche, les vulnérabilités du compilateur Solidity concernent les problèmes lors de la conversion de Solidity en code EVM.

Les vulnérabilités du compilateur Solidity n'affectent pas directement le réseau Ethereum, mais peuvent entraîner une divergence entre le code EVM généré et les attentes des développeurs. Étant donné que les contrats intelligents impliquent souvent des actifs cryptographiques, tout bug causé par le compilateur peut entraîner des pertes d'actifs pour les utilisateurs, avec des conséquences graves.

Il est difficile de déceler les vulnérabilités du compilateur uniquement en examinant le code source du contrat. Il est nécessaire d'analyser en conjonction avec la version spécifique du compilateur et les modèles de code pour déterminer si le contrat 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 les formes spécifiques, les causes et les 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 run() renvoie (uint256) { a = a + 1; return b; } }

La variable de stockage b n'ayant pas été modifiée, la fonction run() devrait retourner la valeur par défaut 0. Cependant, dans certaines versions de compilateurs vulnérables, run() retournera 1.

Cette situation inattendue, si la variable b est utilisée pour des validations d'accès ou la comptabilité des actifs, pourrait entraîner des conséquences graves.

La raison de ce phénomène est que l'EVM utilise des éléments de pile et des emplacements de stockage de taille 32 octets, tandis que Solidity prend en charge des types de données plus petits comme uint32. Lors du traitement de ces types, le compilateur doit effacer les bits de poids fort, mais il n'a pas été correctement géré lors d'un dépassement d'entier, entraînant l'écriture d'un 1 de poids fort dans le stockage, écrasant la variable b.

SOL-2022-4 InlineAssemblyMemorySideEffects

Cette vulnérabilité existe dans les compilateurs des versions >=0.8.13 et <0.8.15.

Considérez le code suivant :

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

Cette vulnérabilité provient d'une optimisation de compilation. Le compilateur essaie de supprimer des opérations d'écriture en mémoire apparemment redondantes, mais analyse incorrectement en traversant des blocs d'assembly. Dans la version vulnérable, la fonction f() renverra 0, au lieu du bon 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Cette vulnérabilité affecte les compilateurs de version >= 0.5.8 et < 0.8.16.

Considérez le code suivant:

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

En temps normal, ce code devrait retourner la valeur de la variable a "aaaa". Mais dans la version vulnérable, il retournera une chaîne vide "".

Cela est dû à la façon dont Solidity nettoie incorrectement certaines données lors de l'opération abi.encode sur les tableaux de type calldata, ce qui entraîne la modification de données adjacentes et provoque une incohérence entre les données encodées et décodées.

Il est à noter que Solidity exécute implicitement abi.encode lors d'appels externes et d'émissions d'événements, c'est pourquoi l'impact de ce type de vulnérabilités peut être plus large que prévu.

Conseils de sécurité

Sur la base de l'analyse du modèle de menace des vulnérabilités du compilateur Solidity et du suivi des vulnérabilités historiques, voici quelques recommandations pour les développeurs et les professionnels de la sécurité :

Pour les développeurs:

1. Utilisez une version plus récente du compilateur Solidity. Les nouvelles versions corrigent généralement les problèmes de sécurité connus.

2. Améliorer les tests unitaires. La plupart des bogues au niveau du compilateur entraînent des résultats d'exécution du code qui ne correspondent pas aux attentes. En augmentant la couverture du code, il est possible de détecter ce type de problème lors de la phase de test.

3. Évitez d'utiliser des opérations telles que l'assemblage en ligne et le décodage/encodage ABI complexe. La plupart des vulnérabilités historiques sont liées à ces caractéristiques complexes.

pour le personnel de sécurité :

1. Ne négligez pas les risques de sécurité que le compilateur peut introduire lors de l'audit. L'élément de vérification associé à la classification des faiblesses des contrats intelligents (SWC) est SWC-102.

2. Dans le processus interne SDL, incitez l'équipe de développement à mettre à jour la version du compilateur Solidity et envisagez d'introduire des vérifications automatiques dans le CI/CD.

3. Il n'est pas nécessaire de s'inquiéter excessivement 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.

Ressources pratiques:

• Alerte de sécurité publiée par l'équipe Solidity :
• Liste des bugs officiels de Solidity :
• Liste des bugs des compilateurs de chaque version :
• Le symbole d'avertissement en haut à droite de la page du code de contrat Etherscan peut signaler les vulnérabilités de sécurité existant dans la version actuelle du compilateur.

Résumé

Cet article présente le concept des vulnérabilités du compilateur Solidity, analyse les risques de sécurité qu'elles peuvent entraîner dans le développement réel d'Ethereum, et offre des conseils pratiques de sécurité aux développeurs et aux professionnels de la sécurité. En comprenant les caractéristiques et les impacts des vulnérabilités du compilateur, il est possible de mieux garantir la sécurité des contrats intelligents.