XRP Ledger: overflow nel payment engine e ruolo dell'AI

Il 9 ottobre XRPL ha reso pubblico un overflow nel payment engine di xrpld che avrebbe permesso di creare XRP spendibili oltre l'offerta totale. Segnalato il 22 settembre da Cayden Liao e Veria AI, corretto il 25 con un rilascio d'emergenza senza amendment. RippleX non ha trovato prove di sfruttamento. Cosa è successo e cosa ne deriva per chi scrive software finanziario.

AICybersecurityCybersecurityAIFintechCryptoXRP LedgerVulnerability managementBug bounty

Articolo

Quattro dati sul bug di overflow dell'XRP Ledger
Dati dal rapporto di XRPL e dal blog di Veria Labs. Fonti in fondo.

Il 9 ottobre XRPL ha pubblicato il rapporto su due vulnerabilità corrette in xrpld 3.4.1, il software dei nodi dell’XRP Ledger. La più grave è un overflow nel payment engine che avrebbe permesso di creare XRP spendibili. Il rapporto la definisce critica se sfruttata e aggiunge: “We have found no evidence that this issue was exploited on any public network”.

Veria Labs ha raccontato la scoperta sul proprio blog con il titolo “The Biggest Hack in Crypto History That Never Happened”. Non c’è stato nessun furto: si tratta di una vulnerabilità segnalata e corretta prima di qualunque sfruttamento noto.

Il bug

Quando un pagamento consuma più offerte del libro ordini, il payment engine somma gli importi in XRP. La somma usava un intero a 64 bit senza controllo di overflow: superato il valore massimo, il totale ripartiva da un numero piccolo. Il risultato era che i titolari delle offerte venivano pagati per intero mentre a chi pagava veniva addebitato solo il totale ridotto.

Esiste un controllo, l’invariante “no XRP created”, pensato proprio per impedire la creazione di XRP. Usava la stessa aritmetica senza controllo e quindi non se ne accorgeva.

Secondo la ricostruzione di Veria bastavano circa 256 conti finanziati con le relative offerte, senza alcun privilegio sui validatori. Il rapporto di XRPL conferma che l’attacco era economico: il costo principale erano riserve e commissioni. Secondo il rapporto il bug era probabilmente presente dal 2015, quando è stato scritto l’attuale payment engine; Veria data l’invariante al febbraio 2017.

La correzione senza amendment

  • 22 settembre: segnalazione tramite il bug bounty di XRPL, accreditata a Cayden Liao e Veria AI. Il segnalatore l’aveva classificata Major, RippleX l’ha portata a critica dopo averla riprodotta.
  • 25 settembre: rilascio d’emergenza di xrpld 3.4.1. Lo stesso giorno oltre l’80% dei validatori della UNL predefinita era aggiornato.
  • 9 ottobre: pubblicazione del rapporto.

La correzione aggiunge un controllo di overflow nella somma delle offerte e un contatore più ampio nell’invariante. È entrata in vigore man mano che i nodi si aggiornavano, senza passare dal voto di un amendment, la procedura che di norma richiede settimane. XRPL spiega la scelta con la gravità: xrpld è open source e pubblicare la correzione avrebbe rivelato il bug per tutto il periodo di attivazione. Il rapporto aggiunge che fermare la rete sarebbe stato preferibile a elaborare transazioni di attacco.

Il ruolo dell’AI

Il rapporto di XRPL accredita la segnalazione a Cayden Liao e Veria AI ma non dice come sia stata trovata. Il resto viene da Veria. Secondo l’azienda il suo agente AI ha individuato le due falle e costruito un proof of concept su una rete locale, poi verificato da una persona. Veria scrive anche che, dopo la segnalazione, agenti di coding generici puntati direttamente sul codice vulnerabile non sono riusciti a trovarlo. Indica inoltre una ricompensa di 250.000 dollari. Sono affermazioni dell’azienda, non verificate in modo indipendente.

Cosa ne deriva

Per la cybersecurity. Un bug rimasto nascosto per circa dieci anni, in codice che secondo Veria ha avuto più di una dozzina di audit e audit contest solo dal 2024, è emerso da un’analisi assistita dall’AI. Veria ne trae la tesi che l’AI renda più economico trovare vecchi bug, per chi difende e per chi attacca. Su un singolo caso resta un’indicazione, coerente con quanto dichiarano i produttori dei modelli: anche Google presenta le capacità di Gemini 4 Argon come strumento per i difensori.

Per chi scrive software finanziario. L’errore è aritmetico: una somma di importi che supera la capacità del tipo di dato. Il caso mostra due cose:

  • un controllo di sicurezza protegge solo se non condivide i difetti di ciò che controlla: qui invariante e codice principale usavano la stessa aritmetica;
  • fermarsi in caso di errore limita il danno. Veria osserva che compilare con il trapping degli overflow avrebbe trasformato il bug in un crash del nodo: un disservizio al posto della creazione di valore.

Per le infrastrutture crypto e fintech. In un progetto open source la correzione stessa rivela il problema e la velocità di aggiornamento dei nodi diventa parte della sicurezza. In questo caso oltre l’80% dei validatori della UNL predefinita era aggiornato il giorno del rilascio. Dal 9 ottobre, con l’attivazione di fixBatchV1_2 (l’amendment che corregge l’altro bug del rapporto), i nodi precedenti alla 3.4.1 sono bloccati e non restano sincronizzati con la rete.

Cosa resta incerto

  • Quale parte della scoperta si debba all’agente AI e quale al lavoro umano: il rapporto ufficiale non lo dice.
  • Il valore esposto: le cifre di Veria (l’intera capitalizzazione di XRP) sono stime dell’azienda.
  • Lo stato delle reti che derivano dal codice di xrpld: postfiatd ha integrato la correzione il 10 ottobre, per le altre non ci sono informazioni pubbliche.

Cosa monitorare

  • Altre segnalazioni attribuite a strumenti AI nei programmi di bug bounty, con descrizioni verificabili del metodo.
  • L’aggiornamento delle reti e dei servizi basati sul codice di xrpld.
  • Come i progetti open source gestiscono le correzioni d’emergenza quando la patch rivela il bug.

Fonti

Vuoi supporto?Sei sotto attacco?Stato dei servizi
Vuoi supporto?Sei sotto attacco?Stato dei servizi