XRP Ledger difende la patch d'emergenza per il bug che consentiva XRP illimitati

Gli sviluppatori di XRP Ledger hanno difeso la patch di sicurezza d'emergenza usata per correggere un bug in grado di creare XRP oltre l'offerta fissa della rete, spiegando che non potevano attendere il normale voto bi-settimanale dei validatori senza esporre la vulnerabilità agli attaccanti.

La correzione, rilasciata il 25 settembre, è arrivata tre giorni dopo una segnalazione tramite programma di bug bounty ed è entrata in vigore immediatamente su ogni server che l'ha installata. Secondo quanto dichiarato, è stata la prima sospensione intenzionale del normale processo di aggiornamento dal suo introdotto oltre dieci anni fa.

«Con un voto normale sugli aggiornamenti, la correzione sarebbe rimasta pubblica per settimane prima di entrare in vigore, mettendo a rischio la sicurezza della rete», hanno scritto gli sviluppatori di XRPL in un post su X domenica.

Questa correzione accelerata ha sollevato dubbi sul livello di decentralizzazione di XRPL. Sul proprio sito web, XRPL afferma di essere una blockchain pubblica completamente decentralizzata — un'affermazione centrale negli argomenti secondo cui il suo token nativo, XRP, non è un titolo finanziario.

La correzione di sicurezza di XRPL «ha sollevato molti interrogativi»

Justin Bons, fondatore di Cyber Capital, ha affermato giovedì che commercializzare XRP verso investitori al dettaglio come se fosse decentralizzato equivale a «una frode palese». Ha sottolineato che il rilascio d'emergenza del 25 settembre è stato distribuito solo come binari, ha temporaneamente trattenuto il codice sorgente e ha esercitato pressione sugli operatori per l'aggiornamento.

Tuttavia, la XRPL Foundation ha precisato che la decisione di saltare il normale processo di aggiornamento è stata presa congiuntamente dalla Foundation, da RippleX, dagli sviluppatori principali e dai validatori, dopo aver valutato la gravità del bug.

«Nessuna singola parte avrebbe potuto decidere autonomamente. Ogni validator e operatore di nodo sceglie quale software eseguire, e la versione 3.4.1 è diventata obbligatoria solo dopo un normale voto di aggiornamento, con il supporto di oltre l’80% dei validatori per due settimane. I cambiamenti al protocollo continuano a passare attraverso gli aggiornamenti.»

XRP Kuwait, un operatore indipendente di validatori, ha anch’essa respinto le accuse secondo cui gli aggiornamenti coordinati indicassero un controllo centralizzato.

«Non concordiamo con l’affermazione secondo cui il coordinamento tra operatori nell’effettuare un aggiornamento costituirebbe di per sé prova di controllo centralizzato», ha dichiarato. «Coordinarsi non equivale a controllare. Operatori indipendenti possono valutare una situazione, comunicare tra loro e giungere alla stessa conclusione senza rinunciare alla propria autonomia.»

Il bug avrebbe potuto generare XRP illimitati

Secondo il rapporto ufficiale di divulgazione della vulnerabilità, il bug era un overflow intero nel motore dei pagamenti di XRP Ledger, presente fin dal 2015.

I saldi XRP sono memorizzati come interi a 64 bit con un massimo fisso. Quando una somma superava tale limite, il calcolo si avvolgeva su un numero minore anziché fallire.

Un attaccante avrebbe potuto sfruttare questa vulnerabilità creando centinaia di offerte appositamente strutturate, ciascuna richiedente una quantità molto elevata di XRP, quindi inviando un singolo pagamento che le consumasse tutte.

Il motore avrebbe accreditato a ciascun proprietario di offerta l’intero importo richiesto, addebitando però all’acquirente solo il piccolo totale avvolto. La differenza sarebbe stata rappresentata da nuovi XRP creati e spendibili.

L’attacco richiedeva offerte appositamente costruite e non poteva essere innescato da normali attività di trading, secondo il rapporto. Gli sviluppatori hanno dichiarato di non aver trovato prove che il problema sia stato sfruttato su alcuna rete pubblica.

Rivista: Attacco a Ledger si estende all'UE, l'IA individua un bug da 18 trilioni di XRP: Hodler’s Digest