Teku 26.10.3 et Besu 26.10.2 retirent quatre autorités racines de certification de leurs images Docker après l'incident impliquant l'autorité de certification eMudhra. La version de Teku a été publiée le 27 octobre et celle de Besu le 26 octobre. Les opérateurs utilisant des installations binaires doivent vérifier séparément leur runtime Java.
Pourquoi c'est important
L'incident concernait des clés privées récupérables pour huit autorités de certification intermédiaires emSign G3. eMudhra a indiqué qu'une erreur dans un script avait généré des clés faibles et que les certificats intermédiaires avaient été révoqués après un signalement le 17 octobre. L'avis de sécurité de Teku précise que Java ne vérifie pas la révocation des certificats par défaut. La révocation seule pourrait donc ne pas protéger les runtimes concernés.
Teku indique que les nœuds Ethereum mainnet avec la configuration par défaut et sans URL HTTPS ne sont pas concernés, et ne signale aucune exploitation. Le risque dépend de la configuration : un attaquant devrait intercepter une connexion HTTPS concernée pour usurper l'identité de son point de terminaison. Teku cite parmi les dépendances HTTPS possibles les signataires distants, les nœuds beacon, les clients d'exécution, les builders, les relays et les services de validateurs. Le réseau pair-à-pair de Teku n'est pas concerné, car libp2p et discv5 n'utilisent pas d'autorités de certification.
Impact sur le marché
Les correctifs retirent emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 et AAA Certificate Services des images Docker. Selon Teku, ses images Docker jusqu'à la version 26.10.2, y compris les variantes -jdk25 et -jdk26, contiennent encore une autorité racine concernée. Mettre à jour Java sur l'hôte ne met pas à jour le runtime intégré à ces conteneurs.
La modification de Besu concerne les images Docker. Les utilisateurs des archives tar et zip peuvent encore disposer d'un JDK qui fait confiance aux autorités racines concernées. De même, les utilisateurs des versions binaires de Teku dépendent du runtime Java installé par l'opérateur. Si une connexion concernée est interceptée, un attaquant pourrait usurper l'identité d'un nœud beacon distant, et potentiellement rediriger les frais de proposition ou provoquer des tâches de validateur manquées. Teku avertit également que l'usurpation d'un signataire externe exposé pourrait permettre d'obtenir des signatures de sortie de validateurs. L'authentification client TLS mutuelle limite l'impact cité à un déni de service.
Questions fréquemment posées
-
Quelles versions des clients Ethereum retirent les autorités racines concernées de leurs images Docker ?
Teku 26.10.3 et Besu 26.10.2 retirent quatre autorités racines de certification de leurs images Docker.
-
Pourquoi les installations binaires nécessitent-elles une vérification distincte de Java ?
Les installations binaires utilisent un runtime Java géré par l'opérateur, qui peut encore faire confiance aux autorités racines concernées. Mettre à jour Java sur l'hôte ne modifie pas un runtime intégré à un conteneur.
-
Selon Teku, les nœuds Ethereum mainnet avec la configuration par défaut sont-ils concernés ?
Teku indique que les nœuds mainnet avec la configuration par défaut et sans URL HTTPS ne sont pas concernés par ce problème de certificats. Le projet ne signale pas non plus d'exploitation.
-
Que pourrait-il se passer si une connexion HTTPS concernée était interceptée ?
Un attaquant pourrait usurper l'identité d'un nœud beacon distant, et potentiellement rediriger les frais de proposition ou provoquer des tâches de validateur manquées.
-
Le problème de certificats affecte-t-il le réseau pair-à-pair de Teku ?
Non. Teku précise que son réseau pair-à-pair libp2p et discv5 n'utilise pas d'autorités de certification et n'est pas concerné.
CoinDesk
WuBlockchain
Crypto News
CoinTelegraph
TheBlock
WatcherGuru