Importante Bug di Ethereum (ETH) Potrebbe Essere Finalmente Risolto - U.Today

Correzione per Attacco di Avvelenamento della Cache su Ethereum

Uno dei client di consenso di Ethereum ha implementato una correzione per un attacco di avvelenamento della cache delle chiavi pubbliche dei validatori, come riportato in una richiesta di pull su GitHub. Questa patch affronta una vulnerabilità legata al fork Gloas, che potrebbe portare alcuni nodi a rifiutare firme valide a causa di un errore nella cache globale delle chiavi pubbliche. Gloas è una componente del layer di consenso del prossimo aggiornamento Glamsterdam.

Meccanismo dell'Attacco

Il problema risiede in un meccanismo in cui il client memorizza le chiavi pubbliche dei validatori e i loro indici in una cache globale. Tecnicamente, i depositi già finalizzati dovrebbero fornire gli stessi validatori su ogni catena, anche se la situazione è diversa al confine del fork. L'attaccante ha bisogno di tre depositi in attesa poco prima del fork: il primo è un grande ricarico per un validatore esistente, mentre gli altri due sono nuove chiavi: A, con credenziali di builder, e B, con credenziali di validatore regolari.

Sulla catena canonica, il ricarico consuma il bilancio, quindi A e B vengono elaborati dopo il fork. A diventa un builder e B ottiene il prossimo indice del validatore. Sulla catena laterale dell'attaccante, il validatore ricaricato viene slashed prima del fork e il suo deposito viene saltato. Questo porta A ad essere elaborato prima, prendendo essenzialmente l'indice di B. La cache difettosa assumeva che entrambe le catene avrebbero prodotto gli stessi validatori e importava la chiave di A globalmente. Al momento del fork, i nodi interessati avrebbero rifiutato tutte le firme valide di B sulla catena canonica, causando una biforcazione.

Dettagli della Correzione

Realisticamente, l'attacco è piuttosto complesso, poiché richiede uno slashing al momento giusto e una catena laterale, quindi è improbabile che si verifichi per caso. Secondo la PR, la correzione consiste nell'aggiungere chiavi alla cache globale delle chiavi pubbliche solo una volta che l'epoca di idoneità all'attivazione è finalizzata. Una nuova struttura, HeadPubkeys, combina anche le chiavi dallo stato principale e dalla cache globale, in modo che i nodi non perdano chiavi se la catena si finalizza senza nuovi blocchi.

Resta da confermare se altri client di consenso abbiano avuto un problema simile. In altre parole, man mano che ci si avvicina a Glamsterdam, gli sviluppatori devono prestare attenzione a più casi limite attorno al confine del fork.