Eroare de 10 ani în registrul XRP putea genera XRP din nimic

Ce anume nu funcționa, de fapt?

Problema se afla în codul care procesează plățile prin intermediul bursei descentralizate (DEX) integrate în XRP Ledger. Conform raportului oficial de divulgare a vulnerabilității publicat ieri, atunci când o singură plată consuma mai multe oferte, motorul suma sumele folosind aritmetică pe 64 de biți necontrolată.

Prin mărirea acestei sume la un nivel suficient de ridicat, aceasta „se învârtea în cerc”, ceea ce reprezintă un overflow de întreg. Un număr uriaș devenea astfel unul mic, iar vânzătorii de pe cealaltă parte a tranzacției erau plătiți integral, dar cumpărătorului i se percepea doar suma mică, „învârtită”. Diferența era reprezentată de XRP care nu existase niciodată înainte.

Registrul efectuează o verificare de siguranță, cunoscută sub numele de „invariant”, care ar trebui să confirme că nu se creează niciodată XRP. Această verificare folosea aceeași aritmetică necontrolată, așa că nu a detectat exact eroarea pe care era menită să o identifice. Raportul atribuie defectul motorului de plăți actual, care a fost scris în 2015.

Cât de ieftin ar fi fost un atac?

Raportul arată că costul a constat în câteva sute de XRP blocate ca rezerve, care sunt returnate odată ce obiectele sunt eliminate, plus comisioanele obișnuite de tranzacție. Un atacator ar fi trebuit să plaseze sute de oferte cu prețuri stabilite în mod deliberat eronat și apoi să direcționeze o plată prin intermediul acestora.

Câștigul a fost partea înfricoșătoare, RippleX calificând bug-ul drept critic, deoarece s-ar fi putut crea XRP cheltuibil peste oferta totală într-o singură tranzacție validată. Întregul concept al XRP se bazează pe o limită maximă de 100 de miliarde de tokenuri, astfel încât o emisiune ascunsă ar fi afectat promisiunea fundamentală a activului. De aceea, postări precum cea de la Whale Insider au prezentat-o ca pe o vulnerabilitate care ar fi putut genera „miliarde” de XRP.

Cine l-a descoperit și cât de repede a fost remediat?

Cronologia a fost destul de scurtă și s-a desfășurat după cum urmează:

• 22 septembrie: Cayden Liao și Veria AI și-au prezentat descoperirile prin programul XRPL Bug Bounty, clasificând-o ca „Major”.
• 23 septembrie: RippleX a reprodus problema, a reclasificat-o la nivelul „critic”, iar remedierea a fost integrată.
• 25 septembrie: Xrpld 3.4.1 a fost lansat, iar peste 80% dintre validatorii din Lista de noduri unice (UNL) implicită îl rulau în acea zi.
• 9 octombrie: Dezvăluire publică.

Patch-ul nu a trecut prin votul obișnuit de amendament, ci a fost lansat ca o modificare directă a codului în versiunea 3.4.1 și a intrat în vigoare pe măsură ce fiecare server a fost actualizat. Codul sursă a fost publicat abia după implementare, o măsură standard pentru a evita oferirea unei „hărți” atacatorilor. Contul XRPL Operations a stabilit de atunci versiunea 3.4.1 ca versiune minimă necesară, adăugând:

Nu am găsit dovezi că această problemă a fost exploatată pe vreo rețea publică.

O a doua eroare, cu un grad de gravitate mai redus, a fost remediată în aceeași versiune. Aceasta se referea la modul în care sunt grupate tranzacțiile Batch, iar remedierea sa se regăsește în amendamentul fixBatchV1_2, care a intrat în vigoare pe Mainnet pe 9 octombrie, alături de BatchV1_1. Raportul precizează că nici în acest caz nu s-au pierdut fonduri.

Dezvăluirea a avut loc într-o săptămână nefastă pentru securitatea criptomonedelor, întrucât pierderile legate de dispozitivele Ledger, despre care a raportat Bitcoin.com News, au atins o valoare estimată de 93,4 milioane de dolari. În cele din urmă, Evernorth, susținută de Ripple, se pregătește să înceapă tranzacționarea pe Nasdaq sub simbolul XRPN luni, având în evidențe aproximativ 473 de milioane de XRP. XRP s-a extins, de asemenea, în domeniul finanțelor descentralizate (DeFi), Firelight activând recent protecția seifului în rețea.