Dans le cadre du cours de « Blockchains publiques et privées », il m'a été demander de soumettre la question suivante à une IA et d'en réaliser l'analyse critique.
Comment s'appellent communément les programmes qu'Ethereum peut exécuter, et quel composant informatique lui permet de les exécuter ? Citez trois risques concrets liés à l'utilisation de tels programmes.
« Adopte le rôle d'un auditeur de sécurité spécialisé dans l'écosystème Ethereum. Rappelle d'abord comment s'appellent les programmes exécutés sur ce réseau et quel environnement informatique permet de les faire tourner. Ensuite, détaille trois vulnérabilités ou risques critiques réels inhérents à l'utilisation de ces programmes, en expliquant leurs conséquences. »
Dans l’écosystème Ethereum, les programmes exécutés sur le réseau s’appellent des contrats intelligents (smart contracts). Ce sont des programmes autonomes dont le code et l’état sont déployés sur la blockchain. Ils s’exécutent dans la Ethereum Virtual Machine (EVM), un environnement d’exécution standardisé présent sur chaque nœud du réseau. L’EVM garantit que tous les participants exécutent les mêmes instructions et obtiennent le même résultat.
En adoptant une posture d’auditeur sécurité, trois risques majeurs méritent une attention particulière :
1. Réentrance (Reentrancy)
La réentrance survient lorsqu’un contrat envoie des fonds ou appelle un contrat externe avant d’avoir terminé la mise à jour de son propre état interne. Le contrat externe peut alors rappeler la fonction initiale de manière inattendue avant que les variables critiques aient été mises à jour.
Conséquences :
- Vidage répété de fonds en plusieurs appels.
- Contournement de contrôles de solde.
- Perte massive d’actifs verrouillés dans le contrat.
(Cas historique emblématique : la vulnérabilité exploitée lors de The DAO Hack, qui a entraîné le détournement d’une quantité considérable d’ethers et a conduit à une scission majeure de l’écosystème.)2. Contrôle d’accès défaillant
Beaucoup de contrats possèdent des fonctions sensibles : modifier des paramètres, mettre à jour une adresse critique, retirer des fonds, mettre le contrat en pause, ou effectuer une mise à jour. Une erreur dans les permissions peut exposer ces fonctions.
Exemples :
- Fonction administrative accessible à tous.
- Mauvaise gestion des rôles.
- Initialisation oubliée sur un contrat proxy.
- Clé administrateur compromise.
Conséquences :
- Prise de contrôle totale du contrat.
- Détournement de trésoreries.
- Modification arbitraire des règles du protocole.
- Blocage ou destruction du service.
(Pour un auditeur, l’analyse des privilèges est souvent l’une des premières priorités.)3. Dépendance à des données externes (oracles / manipulation économique)
Les contrats intelligents n’accèdent pas naturellement au monde extérieur. Ils dépendent souvent d’oracles ou de mécanismes de prix. Si une source externe est manipulée ou si la logique économique est fragile, un attaquant peut influencer les décisions du contrat.
Exemples :
- Manipulation temporaire d’un prix sur une plateforme à faible liquidité.
- Oracle mal sécurisé.
- Attaque via prêt flash (flash loan) créant une distorsion momentanée.
Conséquences :
- Emprunts sous-collatéralisés.
- Liquidations injustifiées.
- Extraction frauduleuse de fonds.
- Effondrement économique d’un protocole.
(Ce type de problème est particulièrement critique car le code peut être techniquement correct tout en restant économiquement vulnérable.)Point essentiel d’audit : Dans Ethereum, le risque ne provient pas uniquement des bugs logiciels classiques. Il existe aussi des risques liés au modèle d’exécution distribué, aux interactions entre contrats et à la logique économique. Un contrat parfaitement compilé peut rester catastrophiquement vulnérable si ses hypothèses de sécurité sont mauvaises.
L'analyse produite constitue un solide effort de vulgarisation technique. Les concepts fondateurs sont correctement définis, notamment à travers un vocabulaire précis (Smart Contracts, EVM) et une explication claire du principe de consensus déterministe.
La sélection des vulnérabilités s'avère particulièrement pertinente :
L'illustration de ces mécanismes par des précédents historiques, tel que le piratage de The DAO, vient appuyer le propos avec justesse.
Néanmoins, la réponse s'ouvre sur une erreur conceptuelle notable en qualifiant ces programmes d'« autonomes ». Si cette expression fait écho au postulat philosophique du Code is Law, elle s'avère techniquement inexacte.
Un contrat intelligent est, par nature, inerte : il est dépourvu d'horloge interne ou de planificateur de tâches. Son exécution requiert obligatoirement l'intervention d'un compte externe (EOA - Externally Owned Account) pour initier et financer la transaction. L'usage du terme "autonome" fausse donc la compréhension de la mécanique des protocoles, tout particulièrement en finance décentralisée (DeFi) où l'action d'agents externes est strictement requise pour déclencher des opérations critiques, telles que les liquidations.
Par ailleurs, si les risques sont correctement identifiés, l'exposé manque de profondeur quant aux mécanismes de remédiation :
delegatecall.Enfin, l'analyse oublie l'architecture propre au réseau Ethereum.
En effet, le modèle computationnel n'est pas abordé, ce qui conduit à ignorer la limite de gaz par bloc. Or, c'est précisément cette contrainte de réseau qui rend possibles les attaques par Déni de Service (DoS) en présence de boucles non bornées.