Ethereum (ETH) aurait pu tomber depuis 2019 – Petits secrets autour d’une grosse vulnérabilité

Le jour où Ethereum aurait pu tomber – Les développeurs d’Ethereum viennent de faire la lumière sur un bug présent depuis 2019 qui aurait pu avoir des conséquences dramatiques sur le réseau. Heureusement, celui-ci a pu être récemment corrigé sans n’avoir jamais été exploité. 

Une faille qui aurait pu faire tomber Ethereum

Le 18 mai, les développeurs du réseau Ethereum ont abordé un sujet jusqu’ici maintenu secret. En effet, le rapport publié sur le site de la fondation Ethereum explique qu’un vecteur d’attaque existait sur le réseau Ethereum, pouvant potentiellement rendre inutilisable la chaîne. 

En octobre 2019, 2 chercheurs en matière de cyber-sécurité, Hubert Ritzdorf et Matthias Egli avait déjà publié un papier faisant froid dans le dos. Celui-ci présentait une méthode d’attaque assez inquiétante. Heureusement, une fois celle-ci révélée, les développeurs des différents clients Ethereum ont été mis au parfum afin de résoudre le problème en question. 

Dans les faits, il s’agissait d’une attaque DoS (ou attaque par déni de service). Celle-ci aurait pu paralyser le réseau Ethereum, en entraînant des temps de blocs de l’ordre de la minute. Le plus impressionnant : elle aurait pu être menée, avec seulement quelques dizaines de milliers de dollars. 

Au final, il aura fallu attendre jusqu’en avril 2021 et le déploiement du hardfork Berlin pour que le vecteur d’attaque soit invalidé, réduisant l’efficacité de l’attaque par un facteur 50.

« Les chiffres (approximatifs) indiquent que Berlin a réduit l’efficacité de l’attaque par 5 et que les snapshots la réduisent par 10, soit une réduction totale de l’impact d’un facteur 50. Nous estimons qu’actuellement, sur le mainnet (15 millions de gaz), il serait possible de créer des blocs qui prendraient 2,5-3 secondes à exécuter sur un nœud geth sans snapshots. Ce chiffre continuera à se détériorer (pour les nœuds sans snapshots), à mesure que l’état se développe. »

Rapport d’Ethereum

Le fond du problème

Il faut revenir sur le fonctionnement d’Ethereum pour bien comprendre le fameux problème. En réalité, l’état d’Ethereum s’apparente à un arbre Patricia-Merkle, où à mesure que le réseau grandit, le nombre de branches et de feuilles de l’arbre augmente.

Ainsi, lorsqu’un tri est effectué pour trouver un compte, 8 à 9 opérations de résolution sont effectuées. Ces opérations entraînent de fait des opérations sur la chaîne et de la consommation de gas. 

En somme, l’attaque imaginée par les 2 chercheurs cherchait à « déclencher des recherches aléatoires de tri ». 

Selon la fonction Solidity utilisée, cela avait entraîné des temps de blocs allant de 38 à 90 secondes, en fonction du fait que les nœuds soient Geth ou Parity. Pour rappel, le temps de bloc moyen sur Ethereum est de l’ordre de 13 secondes.

En outre, cette attaque devient de plus en plus efficace à mesure que l’état d’Ethereum grandit, ce qui est le cas lorsqu’on s’intéresse au nombre de nouvelles adresses créées chaque jour. Une première solution a été de mettre en place un système de snapshot au sein des nœuds du réseau en octobre 2019, permettant de réduire le nombre d’opérations à réaliser par le nœud. 

Pour mitiger pour de bon ce vecteur d’attaque, les développeurs ont finalement proposé les EIP 2929 et 2930, visant à augmenter le coût en gas de certaines opérations. Ces 2 EIP ont été intégrés au mainnet lors du hard fork Berlin. 

Ce n’est pas la première fois que l’on rencontre ce genre de situation. En effet, en septembre 2020, une faille avait également été découverte sur le Lightning Network de Bitcoin. Heureusement, dans les 2 cas, les vecteurs d’attaques n’ont pas été exploités avant d’être corrigés.