Einer der Konsens-Clients von Ethereum hat einen Fix zusammengeführt für einen Angriff zur Vergiftung des Validator-Pubkey-Caches, laut einem Pull Request auf GitHub. Der Patch behebt eine Schwachstelle rund um den Gloas-Fork, die dazu führen könnte, dass einige Nodes gültige Signaturen aufgrund eines Fehlers im globalen Pubkey-Cache ablehnen.
Gloas ist der Consensus-Layer-Teil des bevorstehenden Glamsterdam-Upgrades.
Drei Einzahlungen, zwei Chains
Das Problem liegt in einem Mechanismus, bei dem der Client Validator-Public-Keys und ihre Indizes in einem globalen Cache speichert.
Technisch gesehen sollten bereits finalisierte Einzahlungen auf jeder Chain dieselben Validatoren ergeben, doch an der Fork-Grenze sieht es anders aus.
Der Angreifer benötigt 3 ausstehende Einzahlungen kurz vor dem Fork. Die erste ist ein großer Top-up für einen bestehenden Validator. Die anderen beiden sind neue Keys: A mit Builder-Credentials und B mit regulären Validator-Credentials.
Auf der kanonischen Chain verbraucht der Top-up den Balance-Churn, sodass A und B nach dem Fork verarbeitet werden. A wird ein Builder, und B erhält den nächsten Validator-Index.
Auf der Side-Chain des Angreifers wird der aufgestockte Validator vor dem Fork geslasht, und seine Einzahlung wird übersprungen. Dies führt dazu, dass A früher verarbeitet wird und im Wesentlichen den Index von B übernimmt.
Der fehlerhafte Cache ging davon aus, dass beide Chains dieselben Validatoren erzeugen würden, und importierte den Key von A global.
Am Fork würden betroffene Nodes alle gültigen Signaturen von B auf der kanonischen Chain ablehnen und abspalten.
Realistisch betrachtet ist der Angriff etwas kompliziert, da er ein Slashing zum richtigen Zeitpunkt und eine Side-Chain erfordert, sodass er wahrscheinlich nicht versehentlich passiert.
Was ändert der Fix?
Laut dem PR besteht der Fix darin, Keys erst dann zum globalen Pubkey-Cache hinzuzufügen, wenn ihre Aktivierungsberechtigungs-Epoche finalisiert ist.
Eine neue HeadPubkeys-Struktur kombiniert außerdem Keys aus dem Head-State und dem globalen Cache, damit Nodes keine Keys verpassen, wenn die Chain ohne neue Blöcke finalisiert.
Ob andere Konsens-Clients ein ähnliches Problem hatten, ist noch zu bestätigen. Mit anderen Worten: Je näher Glamsterdam rückt, desto mehr Edge Cases rund um die Fork-Grenze müssen Entwickler abfangen.
