Ethereum-ontwikkelaars hebben twee afzonderlijke kwetsbaarheden verholpen die inleg en blockbeloningen van validators in gevaar hadden kunnen brengen: één waarbij zwakke websitecertificaten betrokken waren en één die was ingebakken in de concepregels voor de komende Glamsterdam-upgrade van het netwerk. Teku, een consensusclient, en Besu, een execution client, brachten allebei patches uit om de blootstelling aan te pakken. Ethereum-nodes draaien een consensusclient en een execution client naast elkaar, wat betekent dat beide lagen van de node-stack dezelfde certificaatopruiming nodig hadden.

Teku bracht op 27 oktober versie 26.10.3 uit, één dag nadat Besu op 26 oktober versie 26.10.2 had uitgebracht. Beide releases verwijderen de betrokken certificaatautoriteiten uit de Docker-images die worden gebruikt om Ethereum-nodes te draaien, volgens de releasepagina van Teku.

Zwakke certificaatsleutels gesignaleerd

Onderzoekers ontdekten op 17 oktober dat acht tussenliggende certificaten die door het Indiase eMudhra waren uitgegeven, berustten op privésleutels die aanvallers konden berekenen op basis van openbaar beschikbare informatie. Met die sleutels hadden aanvallers certificaten voor namaakdiensten kunnen uitgeven. eMudhra trok de certificaten in, maar sommige Java-installaties bleven ze vertrouwen, omdat Java standaard geen certificaatintrekking controleert. Zowel Teku als Besu is geschreven in Java, en daarmee bereikte de zwakte de Ethereum-nodebewerkingen.

De ontdekking kwam in dezelfde week dat Google een securitysysteem voor crypto-custody presenteerde dat is ontworpen om privésleutels over afzonderlijke omgevingen te verdelen.

Hoe validatorfees hadden kunnen worden omgeleid

De certificaatzwakte was belangrijk omdat validators afhankelijk zijn van verbindingen met externe diensten. Een aanvaller die zo'n verbinding kon onderscheppen, zou de dienst aan de andere kant kunnen imiteren. Teku waarschuwde dat een vervalste verbinding met een remote node ertoe kon leiden dat block fees werden betaald aan een adres onder controle van een aanvaller. Externe signing-diensten vormden in getroffen configuraties een extra risico, omdat aanvallers handtekeningen konden verkrijgen die beloningen omleiden.

"Een standaard Teku-node op mainnet is niet getroffen en vereist geen actie", aldus Teku. Het clientteam meldde geen bekend misbruik.

Glamsterdam-depositoregels gecorrigeerd

In een afzonderlijk traject herzien ontwikkelaars de voorgestelde Glamsterdam-regels nadat onderzoeker avsetsin een fout in de deposit-routering had geïdentificeerd. Ook stelden ze de Hoodi-testnet-upgrade uit, die voor 26 oktober gepland stond.

Onder het eerdere concept had een builder en een validator die één openbare sleutel deelden, kunnen veroorzaken dat stake-deposits in de rekening van de builder terechtkwamen. Glamsterdam is ontworpen om blockconstructie van validatie te scheiden, en het herziene voorstel sorteert openstaande deposits op withdrawal credentials, waardoor validatordeposits worden onderscheiden van builderdeposits.

Clientteams verwierpen de correctie aanvankelijk op 19 oktober omdat ze het niet eens waren. Vervolgens voegden ontwikkelaars tests toe en voegden ze de herziene regels op 26 oktober samen.

Verschillende vervolgstappen voor node-operators

De Glamsterdam-correctie is opgenomen in de specificaties van Ethereum, maar softwareteams moeten deze nog implementeren. Glamsterdam draaide eerder op de Sepolia-testnet, terwijl Hoodi op een nieuwe activeringsdatum wacht.

Operators die Teku of Besu buiten Docker draaien, moeten Java afzonderlijk bijwerken. Het certificaatrisico had betrekking op betalingen uit Ethereum-gas fees, zoals prioriteitsfees die aan validators worden betaald, en niet op gewone wallet-saldi van gebruikers. Teku adviseerde gebruikers van de niet-ondersteunde Java 26 om over te stappen naar Java 25.

De certificaatpatches lossen de getroffen Docker-images op, terwijl de Glamsterdam-fix nog moet worden overgenomen in het client-ecosysteem van Ethereum.