I client Ethereum Teku e Besu correggono vulnerabilità che mettevano a rischio le ricompense dei validator
Punti chiave
- •Teku ha rilasciato la versione 26.10.3 il 27 ottobre e Besu ha distribuito la versione 26.10.2 il 26 ottobre; entrambi gli aggiornamenti rimuovono le authority certificate eMudhra interessate dalle immagini Docker utilizzate per eseguire i nodi Ethereum.
- •La debolezza dei certificati è sorta perché otto certificati intermedi di eMudhra si basavano su chiavi private che gli attaccanti potevano calcolare da informazioni pubbliche, e il mancato controllo predefinito della revoca dei certificati da parte di Java ha mantenuto esposti i client basati su Java anche dopo la revoca.
- •Teku ha avvertito che una connessione contraffatta a un nodo remoto o a un servizio di firma esterno avrebbe potuto dirottare le fee e le ricompense dei blocchi, ma un nodo mainnet predefinito non richiedeva alcuna azione e non sono state segnalate attività di exploit.
- •Un errore di instradamento dei depositi nelle bozze delle regole di Glamsterdam, identificato dal ricercatore avsetsin, avrebbe potuto inviare i depositi di staking al conto di un builder quando builder e validator condividevano una singola chiave pubblica; le regole riviste ordinano i depositi in sospeso in base alle credenziali di prelievo e sono state integrate il 26 ottobre dopo la iniziale respinta da parte dei team dei client.
- •Gli operatori dei nodi che eseguono Teku o Besu al di fuori di Docker devono aggiornare Java separatamente, con Teku che consiglia agli utenti della versione Java 26, non supportata, di passare a Java 25, e l'aggiornamento della testnet Hoodi è stato rinviato in attesa di una nuova data di attivazione.
Gli sviluppatori di Ethereum hanno risolto due vulnerabilità separate che avrebbero potuto mettere a rischio i depositi dei validator e le ricompense dei blocchi: una riguardava deboli certificati di siti web, l'altra era incorporata nelle bozze delle regole del prossimo aggiornamento Glamsterdam della rete. Teku, un client di consenso, e Besu, un client di esecuzione, hanno entrambi rilasciato patch per affrontare l'esposizione. I nodi Ethereum eseguono un client di consenso e un client di esecuzione in parallelo, il che significa che entrambi i livelli dello stack del nodo richiedevano la stessa pulizia dei certificati.
Teku ha rilasciato la versione 26.10.3 il 27 ottobre, un giorno dopo che Besu aveva distribuito la versione 26.10.2 il 26 ottobre. Entrambi i rilasci rimuovono le authority certificate interessate dalle immagini Docker utilizzate per eseguire i nodi Ethereum, come indicato nella pagina dei rilasci di Teku.
Segnalate chiavi di certificato deboli
I ricercatori hanno scoperto il 17 ottobre che otto certificati intermedi emessi da eMudhra, in India, si basavano su chiavi private che gli attaccanti potevano calcolare da informazioni pubblicamente disponibili. Con quelle chiavi, gli attaccanti avrebbero potuto emettere certificati per servizi contraffatti. eMudhra ha revocato i certificati, ma alcune installazioni Java hanno continuato a considerarli affidabili, poiché Java non verifica la revoca dei certificati per impostazione predefinita. Sia Teku che Besu sono scritti in Java, ed è così che la debolezza ha raggiunto le operazioni dei nodi Ethereum.
La scoperta è arrivata nella stessa settimana in cui Google ha presentato in anteprima un sistema di sicurezza per la custodia di criptovalute progettato per dividere le chiavi private tra ambienti separati.
Come le fee dei validator avrebbero potuto essere dirottate
La vulnerabilità dei certificati era rilevante perché i validator dipendono da connessioni a servizi esterni. Un attaccante in grado di intercettare tale connessione potrebbe impersonare il servizio dall'altro capo. Teku ha avvertito che una connessione contraffatta a un nodo remoto avrebbe potuto causare il pagamento delle fee dei blocchi a un indirizzo controllato dall'attaccante. I servizi di firma esterni rappresentavano un ulteriore rischio nelle configurazioni interessate, poiché gli attaccanti avrebbero potuto ottenere firme che dirottano le ricompense.
"Un nodo Teku predefinito su mainnet non è interessato e non richiede alcuna azione", ha dichiarato Teku. Il team del client non ha segnalato alcuna attività di exploit nota.
Corrette le regole dei depositi di Glamsterdam
In un'iniziativa separata, gli sviluppatori hanno rivisto le regole proposte per Glamsterdam dopo che il ricercatore avsetsin aveva identificato un errore di instradamento dei depositi. Hanno inoltre rinviato l'aggiornamento della testnet Hoodi, che era previsto per il 26 ottobre.
Secondo la bozza precedente, un builder e un validator che condividevano una singola chiave pubblica avrebbero potuto far entrare i depositi di staking nel conto del builder. Glamsterdam è progettato per separare la costruzione dei blocchi dalla validazione, e la proposta rivista ordina i depositi in sospeso in base alle credenziali di prelievo, distinguendo i depositi dei validator da quelli dei builder.
I team dei client hanno inizialmente respinto la correzione il 19 ottobre per mancanza di accordo. Successivamente gli sviluppatori hanno aggiunto test e hanno integrato le regole riviste il 26 ottobre.
Prossimi passi diversi per gli operatori dei nodi
La correzione di Glamsterdam è entrata nelle specifiche di Ethereum, ma i team software devono ancora implementarla. Glamsterdam è già stato eseguito sulla testnet Sepolia, mentre Hoodi attende una nuova data di attivazione.
Gli operatori che eseguono Teku o Besu al di fuori di Docker devono aggiornare Java separatamente. Il rischio legato ai certificati riguardava pagamenti derivanti dalle gas fee di Ethereum, come le fee di priorità pagate ai validator, e non i saldi ordinari dei portafogli degli utenti. Teku ha consigliato agli utenti della versione Java 26, non più supportata, di passare a Java 25.
Le patch dei certificati risolvono il problema delle immagini Docker interessate, mentre la correzione di Glamsterdam attende l'adozione nell'ecosistema dei client di Ethereum.
