Błąd przepełnienia w XRP Ledger mógł pozwolić na utworzenie w jednej transakcji większej liczby XRP niż wynosi cała istniejąca podaż. RippleX, dział rozwojowy Ripple, oraz XRPL Foundation ujawniły i naprawiły lukę, która prawdopodobnie istniała od 2015 roku, pod koniec września 2026 roku. Nie ma dowodów na to, że została kiedykolwiek wykorzystana.

Limit podaży, który mógł zostać złamany

XRP Ledger to zdecentralizowany blockchain stojący za XRP. Obsługuje płatności i handel za pomocą wbudowanego arkusza zleceń, a silnik płatności jest komponentem, który dopasowuje płatności do złożonych tam ofert. Całkowita podaż na starcie wynosiła 100 miliardów XRP. Nie ma wydobycia ani inflacji; tylko spalone opłaty transakcyjne nieznacznie zmniejszają podaż. Ten stały limit opiera się na niezmienniku na poziomie księgi — regule, że żadna transakcja nie może tworzyć XRP — i właśnie tę gwarancję podważył błąd przepełnienia.

Wersja 3.4.1 oprogramowania serwerowego xrpld została wydana 25 września, a raport o ujawnieniu luki pojawił się 14 dni później. Wcześniej ponad 80% walidatorów na Default Unique Node List (UNL) dokonało już aktualizacji. Błąd dotyczył xrpld 3.4.0 i wszystkich wcześniejszych wersji. Veria Labs, która zgłosiła błąd, oblicza, że pojedyncza transakcja exploitująca mogłaby utworzyć około 18 bilionów XRP.

Jak exploit mógł wyemitować XRP z niczego

Silnik płatności sumował kwoty wszystkich ofert zużytych przezatność w arkuszu zleceń, używając 64-bitowego dodawania liczb całkowitych bez sprawdzania przepełnienia. Jeśli suma rosła wystarczająco dużej, wartość zawijała się do małej liczby. Każdy właściciel oferty otrzymałby pełną płatność, podczas gdy księga obciążyła kupującego jedynie zawiniętą sumą. Różnica pojawiłaby się jako nowo utworzone XRP.

Dwa zabezpieczenia powinny były temu zapobiec. Jednak niezmiennik stanowiący, że żadna transakcja nie może tworzyć XRP, używał tej samej arytmetyki z przepełnieniem. Ponadto kontrola salda per konto uruchamia się dopiero powyżej całkowitej podaży, a utworzone XRP trafiłyby na wiele kont.

Do ataku sprawca musiałby założyć setki kont, z których każde oferowałoby ułamek tokena w zamian za ogromną ilość XRP. Pojedyncza płatność zużyłaby wtedy wszystkie oferty, a każde zaangażowane konto mogłoby należeć do atakującego. Koszty wyniosłyby kilkaset XRP w odzyskiwalnych rezerwach plus opłaty, więc atakujący nie potrzebował dużego salda początkowego.

Niemniej nikt nie mógł przypadkowo wywołać przepełnienia. Normalne płatności nigdy nie osiągają wymaganej sumy, ponieważ żaden prawdziwy trader nie wystawiałby takich cen. Raport stwierdza również, że nie ma dowodów na wykorzystanie luki w żadnej publicznej sieci. Cayden Liao z Veria Labs mówi, że exploit łączy dwa błędy, z których każdy osobno miałby niską wagę; podejrzewa, że dlatego nikt wcześniej nie odkrył tej wady.

Zgłoszenie przez program bug bounty

Cayden Liao i Veria AI zgłosili lukę 22 września za pośrednictwem programu bug bounty sieci, początkowo oceniając ją jako „Major". RippleX odtworzył atak i podniósł ocenę na „critical", a następnie prywatnie opracował poprawkę. Dzień później poprawka trafiła do gałęzi wydawniczej wersji 3.4.1 i została dostarczona w release kandydacie 3.4.1-rc1. Od tego czasu silnik płatności sprawdza przepełnienie przy sumowaniu kwot ofert; jeśli suma się przepełnia, ta część płatności kończy się niepowodzeniem.

Tylko Veria Labs przekazała szczegóły samego odkrycia. Firma twierdzi, że błąd znalazł agent AI i zbudował działający exploit. W przeciwieństwie do tego raport wymienia jako zgłaszających jedynie Liao i Veria AI. Liczba 18 bilionów XRP pochodzi z obliczeń Liao i równałaby się 184-krotności całkowitej podaży. Veria twierdzi również, że otrzymała maksymalną nagrodę w wysokości 250 000 USD, choć raport nie podaje kwoty. Programy takie jak ten to standardowy mechanizm w głównych sieciach blockchain do nagradzania odpowiedzialnego ujawniania luk.

Według raportu błąd prawdopodobnie istniał w kodzie od czasów rozwoju silnika płatności w 2015 roku i pozostawał niezauważony przez około dekadę. Przypadek wpisuje się w szerszy trend poszukiwania luk wspomaganego przez AI, który szybciej ujawnia wady — z tej perspektywy zgadzają się również deweloperzy RippleX.

Poprawka bez amendmentu

Zmiany zasad w XRP Ledger przechodzą normalnie przez tzw. amendmenty, które wymagają wsparcia ponad 80% zaufanych walidatorów przez dwutygodniowy okres. Ta poprawka jednak zadziałała natychmiast, wraz z aktualizacją każdego serwera. Raport nazywa ją pierwszą celową zmianą tego rodzaju w przetwarzaniu transakcji od wprowadzenia amendmentów. W dniu wydania ponad 80% walidatorów Default UNL działało już na wersji 3.4.1 lub nowszej.

RippleX uzasadnił ten krok oknem czasowym: zwykłe wydanie open-source pokazałoby atakującym, gdzie znajduje się błąd, na tygodnie zanim poprawka zaczęłaby obowiązywać. Członkowie XRPL Foundation, RippleX i walidatorzy XRPL uzgodnili wcześniej, że ryzyko uzasadniało szybkie podejście. W ich opinii tylko najbardziej poważne błędy usprawiedliwiają ten krok, a wszystkie pozostałe zmiany nadal przechodzą przez amendmenty.

"AI zmieniło zasady gry. Nie można przemycić krytycznej poprawki błędu w rutynowym publicznym procesie wydawniczym — zostanie natychmiast wykryta i poddana inżynierii odwrotnej." — Mayukha Vadari, RippleX

Jednak zespół opublikował kod źródłowy 3.4.1 na GitHubie dopiero około dwa tygodnie po plikach binarnych. Justin Bons, założyciel Cyber Capital, skrytykował na X fakt, że XRP działał przez dwa tygodnie na kodzie zamkniętym. Cicha poprawka z opóźnionym ujawnieniem to powszechna praktyka w dziedzinie bezpieczeństwa oprogramowania, ale w zdecentralizowanej sieci z ambicjami zarządczymi pozostaje kwestią sporną.

Drugi błąd w funkcji batch

Wersja 3.4.1 zamknęła również drugi błąd, w funkcji batch (XLS-56), który dotyczył xrpld 3.3.0 i 3.4.0. Batch może zawierać do ośmiu transakcji wewnętrznych, a według specyfikacji każda z nich musi znajdować się w polu o nazwie RawTransaction. Serwer tego nie sprawdzał. W rezultacie mogł powstać trwale uszkodzony wpis w księdze, który mógłby zakłó działanie indekserów, eksploratorów i SDK.

Poważniejszy był wariant dotyczący konsensusu. Przy mieszanych wersjach oprogramowania spreparowana transakcja mogłaby zatrzymać walidację kosztem jednej opłaty transakcyjnej, choć atakujący nie zyskałby nic on-chain. Mainnet nie odnotował żadnego wpływu, ponieważ BatchV1_1 nie był tam aktywny.

Odkrycie po raz pierwszy wyszło na jaw podczas Sherlock Attackathon, początkowo ocenione jako „low". 18 września Denis Angell z XRPL Foundation potwierdził, że wcześniejsza poprawka była niekompletna. Cztery dni później Mayukha Vadari zidentyfikowała ryzyko dla konsensusu. Ripple oraz operator walidatora Vet wycofali następnie swoje głosy za BatchV1_1, amendmentem pierwotnie mającym aktywować się 29 września. Wydanie uruchomiło dwutygodniową aktywację fixBatchV1_2, a od 9 października oba amendmenty są aktywne w mainnecie.

Zaostrzony proces przeglądu

RippleX zmienia zatem swój proces przeglądu. Od teraz każde znalezisko bezpieczeństwa oznaczone jako naprawione przechodzi nowy test względem release kandydata, a zespół zamyka je dopiero wtedy, gdy test odtworzy oryginalny błąd, a kandydat przejdzie testy. Wśród dodatkowych zabezpieczeń wymienionych w raporcie są publiczne attackathony i red teaming wspomagany przez AI.

Starsze wersje są uznawane za „amendment-blocked" i nie pozostają już zsynchronizowane. Operatorzy muszą zatem zaktualizować swoje serwery do xrpld 3.4.1 lub nowszej wersji.

Źródło: raport o ujawnieniu luki XRPL za pośrednictwem Crypto Valley Journal