Les clients Ethereum corrigent une faille qui aurait pu détourner les récompenses en ETH

Une défaillance cryptographique chez une société indienne de certificats s’est propagée à Ethereum, où elle aurait pu permettre à des attaquants de détourner discrètement à leur profit les récompenses de bloc de certains validateurs. Teku, logiciel utilisé par de nombreux validateurs pour faire tourner la composante proof-of-stake d’Ethereum, a publié mardi la version 26.10.3. Besu, qui traite les transactions Ethereum, a publié lundi la version 26.10.2. Les deux mises à jour cessent de faire confiance aux certificats liés à eMudhra, autorité de certification indienne, dans leurs images Docker, versions préassemblées utilisées par de nombreux opérateurs. Les validateurs sont les ordinateurs qui mettent en jeu des ETH pour sécuriser Ethereum et perçoivent des frais pour proposer des blocs. Certains communiquent avec d’autres services via Internet et s’appuient sur des certificats numériques pour vérifier l’identité de leur interlocuteur. Le 17 octobre, des chercheurs ont constaté que les clés privées de huit autorités de certification intermédiaires d’eMudhra avaient été générées avec un aléa insuffisant. Ces clés pouvaient être reconstituées à partir des certificats eux-mêmes, qui sont publics. Quiconque détenait ces clés pouvait émettre des certificats que des logiciels non corrigés auraient acceptés comme authentiques. Les navigateurs ont bloqué les certificats, eMudhra les a révoqués le lendemain et a depuis annoncé son retrait du secteur des certificats. Java, langage sur lequel reposent Teku et Besu, ne vérifie pas par défaut si un certificat a été révoqué. Les images Docker de Teku continuaient de faire confiance aux certificats compromis après leur blocage par les navigateurs. Un attaquant positionné entre un validateur et un service auquel il se connecte pouvait se faire passer pour ce service. Dans son avis de sécurité, Teku indique qu’un validateur ainsi trompé pouvait proposer un bloc dont les frais étaient versés à l’adresse de l’attaquant. Un faux signataire externe, service distinct qui détient les clés d’un validateur, pouvait transmettre des signatures permettant de modifier la destination des récompenses, configuration que Teku classe comme la plus risquée. « Un nœud Teku par défaut sur le mainnet n’est pas affecté et ne nécessite aucune action », écrit l’équipe, précisant qu’« aucune exploitation n’a été signalée ». Consensys Diligence, partenaire de Teku en matière de sécurité, a été le premier à alerter. Les opérateurs qui exécutent Teku ou Besu directement sur leur machine, sans Docker, doivent mettre à jour Java eux-mêmes, car la mise à jour du logiciel Ethereum ne modifie pas la liste des certificats de confiance de Java. Les nouvelles images Docker ne corrigent pas non plus Java installé sur l’hôte. Les opérateurs encore sous Java 26 font face à une correction plus délicate : Teku indique que cette version est en fin de vie et ne recevra pas de version corrigée. Ces opérateurs doivent passer à Java 25.