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

Le compilateur est l'un des composants fondamentaux des systèmes informatiques modernes, responsable de la conversion des langages de programmation de haut niveau en instructions exécutables de bas niveau. Bien que les développeurs se concentrent généralement sur la sécurité du code applicatif, la sécurité du compilateur lui-même est tout aussi importante. Les vulnérabilités du compilateur peuvent également entraîner des risques de sécurité graves dans certaines situations, par exemple, les vulnérabilités du moteur JavaScript des navigateurs peuvent entraîner une exécution de code à distance.

Le compilateur Solidity n'échappe pas à la règle, avec plusieurs versions présentant des vulnérabilités de sécurité. Contrairement aux vulnérabilités de l'EVM, les vulnérabilités du compilateur Solidity n'affectent que les développeurs de contrats, sans mettre directement en danger la sécurité du réseau Ethereum. Cependant, cela peut entraîner un code EVM généré qui ne correspond pas aux attentes des développeurs, ce qui peut provoquer des vulnérabilités dans les contrats intelligents et mettre en péril la sécurité des actifs des utilisateurs.

Voici quelques exemples réels de vulnérabilités des compilateurs Solidity :

1. SOL-2016-9 HighOrderByteCleanStorage

Version d'impact : >=0.1.6 <0.4.4

Cette vulnérabilité pourrait entraîner une modification involontaire de la variable storage. Par exemple:

solidité contrat C { uint32 a = 0x1234; uint32 b = 0; function run() returns (uint) { a += 1; return b; } }

La fonction run( devrait retourner 0, mais elle retourne en réalité 1. Cela est dû au fait que le compilateur n'a pas correctement nettoyé les bits de poids fort lors du traitement du dépassement d'entier, ce qui a entraîné l'écriture des bits de dépassement dans une variable adjacente.

2. SOL-2022-4 Effets de bord de mémoire en assembly inline

Version impactée : >=0.8.13 <0.8.15

Cette vulnérabilité provient du processus d'optimisation de la compilation. Par exemple :

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

La fonction f)( doit retourner 0x42, mais la version vulnérable retourne 0. Cela est dû à une erreur du compilateur qui a incorrectement supprimé l'opération d'écriture en mémoire dans le premier bloc assembly.

3. SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Version impactée :>= 0.5.8 < 0.8.16

Cette vulnérabilité concerne le codage ABI du tableau calldata. Par exemple :

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

La fonction f) doit renvoyer le tableau d'entrée, mais la version vulnérable renverra une chaîne vide. Cela est dû à une erreur du compilateur lors du nettoyage des données adjacentes pendant le processus de codage.

Pour réduire le risque de vulnérabilités dans le compilateur Solidity, les développeurs devraient :

• Utiliser une version plus récente du compilateur
• Améliorer les tests unitaires, augmenter la couverture du code
• Évitez d'utiliser des caractéristiques linguistiques complexes, telles que l'assemblage en ligne, le codage ABI des tableaux multidimensionnels, etc.

Les auditeurs de sécurité doivent :

• Considérer les risques potentiels du compilateur lors du processus d'audit
• Il est conseillé à l'équipe de développement de mettre à jour la version du compilateur en temps utile.
• Ajouter une vérification automatique de la version du compilateur dans le processus CI/CD

Ressources de référence utiles :

• Blog officiel d'avertissement de sécurité Solidity
• Liste des bugs du dépôt GitHub de Solidity
• Alerte de vulnérabilité du compilateur sur la page de contrat d'Etherscan

En résumé, les vulnérabilités des compilateurs, bien que rares, peuvent avoir des conséquences graves. Les développeurs et les professionnels de la sécurité doivent rester vigilants et prendre des mesures appropriées pour réduire les risques.