eMudhra-certificaatfout zet Teku en Besu aan tot Docker-fixes; gebruikers van binaire versies moeten Java apart controleren
De Ethereum-clientsoftware Teku en Besu hebben Docker-updates uitgebracht die het vertrouwen in vier certificaatroots verwijderen die verband houden met een compromittering bij certificaatautoriteit eMudhra. Binaire installaties moeten de Java-runtime waarop ze vertrouwen apart controleren, omdat het bijwerken van de client die runtime niet verandert.
Geschreven door de AI-redactie van CoinArticle · op basis van 2 geciteerde bronnen. Hoe we werken
Wat de releases veranderen
Teku 26.10.3, uitgebracht op 27 oktober, en Besu 26.10.2, uitgebracht op 26 oktober, zorgen ervoor dat hun Docker-images niet langer vertrouwen op vier certificaatroots: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 en AAA Certificate Services. De fixes richten zich op de meegeleverde trust stores, de lijsten met certificaatautoriteiten die Java standaard accepteert.
Beide projecten beperken de fix tot containers. Besu stelt dat de tar- en zip-distributies mogelijk nog een JDK gebruiken die de getroffen roots vertrouwt. De binaire distributie van Teku gebruikt de Java-runtime die de operator heeft geïnstalleerd, dus die operators moeten die runtime apart van de client controleren en, indien nodig, repareren.
Het eMudhra-incident
Het onderliggende probleem betrof herstelbare private keys van acht emSign G3 intermediate certificate authorities. Volgens de incidentverklaring van eMudhra meldde een onderzoeker de zwakke intermediates op 17 oktober, en het bedrijf heeft alle acht de volgende dag ingetrokken. eMudhra erkende een scriptfout die de zwakke keys heeft voortgebracht.
De berichtgeving verschilt over hoe de keys werden misbruikt. Het beveiligingsteam van Go beschrijft dat de private keys binnen microseconden werden hersteld, waardoor een aanvaller een certificaat kon uitgeven voor een domein dat hij niet beheert. Onderzoek van Kudelski Security bekijkt dezelfde certificaathiërarchie en beschrijft het risico als software die een certificaat accepteert dat is ondertekend met een reproduceerbare key. De advisory van Teku merkt op dat Java standaard geen intrekking controleert, waardoor ingetrokken intermediates nog steeds kunnen worden geaccepteerd door niet-gepatchte runtimes.
Blootstelling hangt af van de configuratie
De beveiligingsmelding van Teku stelt dat standaard mainnet-nodes zonder HTTPS-URL's niet worden getroffen en dat er geen misbruik is gemeld. Een aanvaller op een niet-gepatchte runtime zou ook een getroffen HTTPS-verbinding moeten onderscheppen, dus de zwakke key alleen plaatst een aanvaller niet tussen een node en zijn peers.
Waar HTTPS-verbindingen bestaan, verschillen de gevolgen per rol. De HTTPS-afhankelijkheden van Teku kunnen remote signers, beacon nodes, execution clients, builders of relays, metrics-diensten en bronnen voor startgegevens omvatten. Volgens de melding zou een geïmiteerde remote beacon node proposal fees kunnen omleiden of gemiste taken kunnen veroorzaken, en zou een geïmiteerde externe signer handtekeningen voor validator-exits kunnen verkrijgen. Wederzijdse TLS-clientauthenticatie bij de signer beperkt dat tweede geval tot denial of service. De melding wijst ook op Sepolia, Hoodi en Ephemery, die de starttoestand via HTTPS downloaden wanneer ze met een lege database worden gestart. Het peer-to-peer-netwerk van Teku, inclusief libp2p en discv5, gebruikt geen certificaatautoriteiten en valt buiten dit probleem.
Wat operators moeten controleren
Operators moeten eerst bepalen of hun opzet uitgaande HTTPS-verbindingen maakt naar de hierboven genoemde diensten. Docker-gebruikers moeten updaten naar de gepatchte images. De melding van Teku stelt dat alle Docker-images tot en met 26.10.2, inclusief de varianten -jdk25 en -jdk26, de betrokken emSign ECC-root behouden, en dat het bijwerken van Java op de host de runtime binnen een container niet verandert.
Gebruikers van binaire en archiefversies moeten nagaan welke JDK hun node gebruikt en of die de getroffen roots nog vertrouwt. De consensusregels van Ethereum worden door dit incident niet veranderd; het probleem betreft de software en certificaatinfrastructuur rond validators.
Waarom het ertoe doet
Voor traders
Het validator-gerelateerde risico is hier operationeel en niet op protocolniveau. Let daarom op gemelde misbruik of verdere clientreleases voordat u de blootstelling opnieuw beoordeelt.
Voor investeerders
De episode belicht het risico van certificaatautoriteiten van derden in de validator-infrastructuur, wat in de komende maanden kan bepalen hoe node-operators en stakingdiensten beveiligingspraktijken afwegen.
Voor bouwers
Elke dienst die de standaard certificaatstore van Java vertrouwt, moet zijn meegeleverde roots en de afhandeling van intrekking controleren, omdat Java standaard geen intrekking controleert.
Dit artikel is alleen bedoeld ter informatie en is geen financieel advies. Lees de volledige disclaimer.
