Teku et Besu suppriment quatre racines de certificats compromises des images Docker

Teku 26.10.3 et Besu 26.10.2 suppriment quatre racines de certificats compromises de leurs images Docker à la suite d’un incident de sécurité chez eMudhra, un fournisseur d’autorités de certification. Les versions, publiées respectivement le 27 octobre et le 26 octobre, exigent que les opérateurs utilisant des installations binaires effectuent des vérifications distinctes sur leurs environnements Java, car les mises à jour des clients ne modifient pas les magasins de confiance au niveau de l’hôte.

Portée de la correction Docker

La mise à jour spécifique cible les magasins de confiance au sein des environnements conteneurisés des deux clients Ethereum. Les racines supprimées sont emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 et AAA Certificate Services. L’avis de sécurité de Teku identifie toutes ses images Docker jusqu’à la version 26.10.2, y compris les variantes -jdk25 et -jdk26, comme conservant la racine emSign ECC incriminée. La mise à jour de Java sur la machine hôte ne modifie pas l’environnement d’exécution à l’intérieur de ces conteneurs, ce qui signifie que la correction spécifique au conteneur est nécessaire pour éliminer les ancrages de confiance compromis.

Besu limite explicitement sa modification de suppression de racines à ses images Docker. Les utilisateurs ayant installé Besu via des archives tar ou zip peuvent toujours posséder un Kit de développement Java (JDK) qui fait confiance aux racines compromises. De même, la distribution binaire de Teku s’appuie sur l’environnement Java installé par l’opérateur. Pour ces configurations non conteneurisées, la mise à jour du logiciel client ne traite pas la vulnérabilité du magasin de confiance sous-jacent.

Installations binaires et environnement Java

Les opérateurs exécutant des installations binaires doivent vérifier indépendamment leurs environnements Java. Si l’environnement Java sur l’hôte reste affecté par l’incident eMudhra, il doit être corrigé séparément du logiciel client. L’avis de Teku note que Java ne vérifie pas la révocation des certificats par défaut. Par conséquent, même si les certificats intermédiaires compromis étaient révoqués, un environnement Java affecté pourrait toujours leur faire confiance à moins que le magasin de confiance ne soit mis à jour manuellement ou que l’environnement ne soit patché pour imposer des vérifications de révocation.

L’incident sous-jacent impliquait des clés privées récupérables pour huit autorités de certification intermédiaires emSign G3. eMudhra a reconnu une erreur de script qui a produit des clés faibles. L’entreprise a déclaré que les certificats intermédiaires ont été révoqués après un rapport d’incident le 17 octobre. Cependant, comme les configurations Java standard n’effectuent pas de vérifications de révocation, la présence des racines compromises dans le magasin de confiance reste un risque pour les systèmes non corrigés.

Exposition et vecteurs d’attaque

L’avis de sécurité de Teku ne signale aucune exploitation de la vulnérabilité à ce jour. L’équipe déclare que les nœuds mainnet par défaut configurés sans URL HTTPS ne sont pas affectés par ce problème de certificat. L’exposition dépend de configurations spécifiques qui s’appuient sur HTTPS pour la communication. Les dépendances HTTPS de Teku peuvent inclure des signataires distants, des nœuds balise, des clients d’exécution, des constructeurs, des relais, la configuration du proposant, les données de démarrage et les services de métriques.

L’avis signale également les réseaux de test Sepolia, Hoodi et Ephemery. Ces réseaux téléchargent l’état initial via HTTPS lorsqu’ils sont lancés avec une base de données vide, créant un vecteur potentiel de compromission si l’environnement fait confiance aux racines affectées. Sur un environnement non corrigé, un attaquant qui intercepte une connexion HTTPS affectée pourrait se faire passer pour un nœud balise distant. Cette usurpation pourrait rediriger les frais de proposition ou causer des manquements aux devoirs des validateurs. De plus, un attaquant se faisant passer pour un signataire externe exposé pourrait obtenir des signatures pour des sorties de validateurs. L’avis indique que l’authentification client mutuelle TLS sur le signataire limite l’impact d’une telle attaque à une déni de service.

Le réseau pair-à-pair de Teku, qui inclut libp2p et discv5, n’utilise pas d’autorités de certification et est donc hors du périmètre de ce problème. La correction de sécurité est strictement limitée aux points de terminaison HTTPS et aux magasins de confiance qui les valident au sein du logiciel client et de ses environnements Java associés.