Ethereum-consensusclient voegt fix toe voor validator pubkey cachebug

Wat er gebeurde

Een pull request op GitHub meldt dat een consensusclient van Ethereum een fix heeft toegevoegd voor een validator pubkey cache poisoning attack. De patch richt zich op een kwetsbaarheid rond de Gloas fork. Gloas is het consensusdeel van de aankomende Glamsterdam upgrade.

De bug zat in een mechanisme dat publieke sleutels van validators en hun indexen in een globale cache opslaat. Normaal zouden deposits die al final zijn dezelfde validators op elke keten opleveren, maar dat kan rond de fork boundary anders lopen.

De aanval vereist drie pending deposits net voor de fork. De eerste is een grote top-up voor een bestaande validator. De andere twee zijn nieuwe sleutels, genoemd A met builder credentials en B met gewone validator credentials. Op de canonical chain verbruikt de top-up de balance churn, waardoor A en B na de fork worden verwerkt. A wordt builder en B krijgt de volgende validatorindex.

Op een door de aanvaller gemaakte side chain kan de opgewaardeerde validator voor de fork geslasht worden en wordt de deposit overgeslagen. Daardoor wordt A eerder verwerkt en neemt A in feite B’s index. De buggy cache ging ervan uit dat beide ketens dezelfde validators zouden opleveren en importeerde A’s sleutel globaal.

Als gevolg zouden getroffen nodes op het moment van de fork alle geldige handtekeningen van B op de canonical chain afwijzen en afslaan van die keten. De aanval is technisch complex. Hij vereist een slashing op het juiste moment en een side chain, en is daardoor onwaarschijnlijk om per ongeluk te gebeuren.

Volgens de pull request lost de fix het probleem op door sleutels alleen aan de globale pubkey cache toe te voegen nadat hun activation eligibility epoch gefinaliseerd is. Daarnaast introduceert de client een nieuwe HeadPubkeys-structuur die sleutels uit de head state en de globale cache combineert, zodat nodes geen sleutels missen als de keten finaliseert zonder nieuwe blocks. Het is nog niet bevestigd of andere consensusclients hetzelfde probleem hadden. Naarmate Glamsterdam dichterbij komt, moeten ontwikkelaars meer edge cases rond het fork boundary afvangen.

Waarom dit telt

Voor beleggers in ETH betekent dit dat ontwikkelaars actief kwetsbaarheden rond de aankomende Glamsterdam upgrade dichten. Problemen met consensusclients kunnen anders leiden tot netwerkinstabiliteit en verwarring onder nodes.