Il team di sviluppo dell'XRP Ledger (XRPL) ha divulgato il 9 ottobre un difetto di integer overflow che, in condizioni appositamente costruite, avrebbe potuto consentire la creazione di XRP spendibile dal nulla. La correzione è stata rilasciata nella versione 3.4.1 di xrpld il 25 settembre, circa due settimane prima della divulgazione pubblica, e il team ha dichiarato di non aver trovato prove che la vulnerabilità sia mai stata sfruttata su una rete pubblica.

I dettagli sono illustrati nel rapporto di divulgazione della vulnerabilità del 9 ottobre di XRPL.

Un calcolo di pagamento che poteva produrre XRP dal nulla

Il rapporto descrive un difetto di integer overflow nel motore di pagamento del ledger. In condizioni appositamente costruite, un pagamento che consumava molte offerte del order book avrebbe potuto accreditare conti con XRP che il mittente non aveva effettivamente pagato. Gli order book sono una struttura nativa di XRPL, parte dello scambio integrato nel ledger, quindi l'aritmetica difettosa si trova nel codice che sostiene sia il trading sia i pagamenti sul ledger.

Ogni singola offerta nella transazione poteva appaire valida di per sé. Il guasto si verificava quando il motore sommava gli importi in XRP di tutte. Una volta che il totale superava la dimensione massima del utilizzato per quel calcolo, poteva andare in wrap-around verso un valore molto più piccolo invece di generare un errore.

In quello scenario, il motore avrebbe comunque accreditato ai proprietari delle offerte i loro importi completi in XRP, addebitando all'acquirente solo il totale ridotto dal wrap-around. La differenza rappresentava XRP di nuova creazione, che poteva poi essere spostato, scambiato o inviato a un exchange come qualsiasi altro saldo.

Perché il difetto era grave

L'attacco non richiedeva un grande saldo in XRP. Un attaccante avrebbe potuto controllare i conti che piazzavano le offerte, pagare le riserve di conto necessarie e le commissioni di transazione, per poi distribuire l'XRP creato attraverso quei conti.

La vulnerabilità riguardava l'aritmetica dei pagamenti e non l'accesso ai wallet, lasciando intatte le chiavi dei conti. Per attivarla erano necessarie centinaia di offerte con prezzi appositamente calcolati e una transazione progettata per consumarle insieme; un normale pagamento o scambio in XRP non si avvicinava ai valori necessari per generare l'overflow.

Per un ledger, pochi difetti sono sensibili quanto uno in grado di coniare unità spendibili, perché ogni saldo dipende dal fatto che il nuovo XRP entri in circolazione solo attraverso le regole definite dalla rete.

XRPL ha dichiarato di non aver trovato prove di sfruttamento su una rete pubblica, e non sono stati segnalati compromissioni di chiavi private, perdite di fondi o guasti di consenso. Il difetto sembra essere presente da quando l'attuale motore di pagamento è stato scritto nel 2015, rimanendo scoperto perché l'attività normale non ha mai raggiunto il limite aritmetico.

Anche la protezione esistente del ledger contro l'XRP di nuova creazione si basava sullo stesso tipo di addizione. Poteva andare in wrap-around allo stesso modo del motore di pagamento, facendo apparire la transazione normale invece di segnalare l'aumento inatteso dei saldi.

Perché gli sviluppatori hanno usato un deployment d'emergenza

Gli sviluppatori hanno rilasciato la correzione dell'overflow prima di pubblicarne i dettagli tecnici, perché una normale tempistica di emendamento avrebbe lasciato un exploit noto disponibile per settimane. La patch è stata rilasciata nella versione 3.4.1 di xrpld il 25 settembre, mentre la divulgazione pubblica è avvenuta il 9 ottobre.

XRPL di solito modifica le regole delle transazioni tramite emendamenti. I validator aggiornano prima il loro software, poi mantengono il supporto rich per un periodo prestabilito prima che la nuova regola si attivi allo stesso punto del ledger su tutta la rete. Tale processo evita situazioni in cui server diversi giungono a conclusioni diverse sulla stessa transazione.

Attendere quel processo avrebbe creato un problema difficile in questo caso. Poiché xrpld è open source, pubblicare la riparazione avrebbe potuto mostrare agli attaccanti dove guardare, mentre il software più vecchio accettava ancora il percorso di transazione vulnerabile. Il team ha quindi fatto sì che il nuovo controllo dell'overflow diventasse effettivo quando un singolo server veniva aggiornato.

Questo approccio più rapido comportava un rischio temporaneo di compatibilità: un server non patchato avrebbe potuto accettare una transazione di exploit rifiutata da un server aggiornato. Gli sviluppatori hanno ritenuto tale rischio meno pericoloso che consentire all'XRP creato di entrare sul mercato. Secondo il rapporto, oltre l'80% dei validator dell'UNL predefinito si era aggiornato il giorno del rilascio della versione 3.4.1.

La divulgazione riguardava un secondo difetto separato

Il rapporto dettaglia anche un problema di validazione nella prossima funzionalità Batch di XRPL, che consente agli utenti di inviare più transazioni come un'unica unità. Il difetto avrebbe potuto far sì che server che eseguono versioni diverse del software discordassero su una transazione Batch malformata, interrompendo la validazione del ledger o rompendo le applicazioni che analizzano i dati delle transazioni.

Il difetto del Batch è stato individuato prima che la funzionalità raggiungesse la mainnet. Il problema dell'overflow, al contrario, riguardava il codice esistente del motore di pagamento, motivo per cui la sua patch non poteva attendere un ciclo di attivazione standard. Con la funzionalità stessa ancora in arrivo, il suo debutto sulla mainnet con la correzione di validazione già in atto è la parte di questa divulgazione che resta avanti.

Il rapporto è arrivato mentre XRPL stava anche attivando nuovi strumenti di controllo dei conti per le imprese. Le modifiche riguardano parti diverse del ledger, ma entrambe dipendono dal fatto che operatori di nodo, fornitori di wallet e sviluppatori seguano le stesse regole correnti.

Cosa devono fare utenti e operatori

I normali possessori di XRP non hanno bisogno di spostare fondi, sostituire il wallet o scambiare i propri token. L'aggiornamento riguarda il software che valida le transazioni, non i saldi dei conti, le chiavi dei wallet o l'offerta di XRP detenuta dagli utenti.

• Possessori di XRP: nessuna azione richiesta.
• Utenti di exchange: seguire gli avvisi della piattaforma se un exchange esegue manutenzione sulla propria infrastruttura XRPL.
• Operatori di nodo: eseguire l'aggiornamento a xrpld 3.4.1 o versione successiva per restare sincronizzati con la rete. I server più vecchi sono ora amendment-blocked in seguito all'attivazione della correzione del Batch, il che significa che non possono continuare a seguire le regole correnti del ledger finché non si aggiornano.

La correzione ha protetto le regole di offerta dell'XRP prima che venissero messe alla prova

La divulgazione mostra quanto il ledger sia stato vicino a un fallimento dell'integrità dell'offerta e perché i validator hanno agito rapidamente. Il difetto è stato corretto prima che i suoi dettagli diventassero pubblici, non è stato trovato alcun exploit, e il motore di pagamento ora utilizza controlli progettati per fermare la stessa classe di errori aritmetici prima che raggiungano un ledger validato. Resta da vedere, dall'esterno, quanto rapidamente il resto della rete convergerà su xrpld 3.4.1 o versioni successive, visto che i server non patchati sono già amendment-blocked e non possono seguire il ledger corrente.

Questo articolo ha finalità puramente informative e non costituisce consulenza finanziaria o tecnica. Gli operatori di nodo dovrebbero consultare l'attuale documentazione dei rilasci XRPL prima di aggiornare l'infrastruttura di produzione.

Questo articolo è basato su un servizio pubblicato originariamente da Coindoo.