10-letni błąd XRP Ledger mógł pozwolić generować XRP z niczego

Co tak naprawdę nie działało?

Problem tkwił w kodzie odpowiedzialnym za rozliczanie płatności w ramach wbudowanej w XRP Ledger zdecentralizowanej giełdy (DEX). Zgodnie z opublikowanym wczoraj oficjalnym raportem dotyczącym ujawnienia luki, gdy pojedyncza płatność obejmowała wiele ofert, silnik sumował kwoty przy użyciu niesprawdzonej arytmetyki 64-bitowej.

Po zwiększeniu tej sumy do wystarczająco wysokiej wartości następowało „zaokrąglenie”, co jest typowym skutkiem przepełnienia liczby całkowitej. Ogromna liczba stawała się wówczas małą, a sprzedający po drugiej stronie transakcji otrzymywali pełną kwotę, podczas gdy kupujący był obciążany jedynie zaokrągloną, niewielką sumą. Różnica stanowiła XRP, które nigdy wcześniej nie istniało.

Rejestr przeprowadza kontrolę bezpieczeństwa, znaną jako „inwariant”, która ma potwierdzić, że XRP nigdy nie jest tworzone. Kontrola ta wykorzystywała tę samą niesprawdzoną arytmetykę, więc nie była w stanie wykryć dokładnie tej usterki, do wykrycia której została stworzona. Raport wskazuje, że błąd ten wynika z obecnego silnika płatności, który został napisany w 2015 roku.

Jak tani byłby taki atak?

Raport wskazuje, że kosztem było kilkaset XRP zablokowanych jako rezerwy, które są zwracane po usunięciu obiektów, plus zwykłe opłaty transakcyjne. Atakujący musiałby złożyć setki celowo błędnie wycenionych ofert, a następnie przekierować przez nie jedną płatność.

Najbardziej przerażająca była potencjalna korzyść – firma RippleX określiła ten błąd jako krytyczny, ponieważ w ramach jednej zatwierdzonej transakcji mogłoby powstać więcej XRP do wydania niż wynosi całkowita podaż. Cała koncepcja XRP opiera się na sztywnym limicie 100 miliardów tokenów, więc ciche wyemitowanie nowych tokenów podważyłoby podstawową obietnicę tego aktywa. Dlatego też w postach, takich jak ten opublikowany przez Whale Insider, błąd ten przedstawiono jako potencjalne źródło „miliardów” tokenów XRP.

Kto go wykrył i jak szybko został naprawiony?

Czas trwania zdarzenia był dość krótki i wyglądał następująco:

• 22 września: Cayden Liao i Veria AI zgłosili swoje odkrycie w ramach programu XRPL Bug Bounty, oceniając je jako „poważne”.
• 23 września: RippleX odtworzyło błąd, podniosło jego rangę do „krytycznej”, a poprawka została wdrożona.
• 25 września: Wydano wersję Xrpld 3.4.1, a tego dnia korzystało z niej ponad 80% domyślnych walidatorów z listy UNL (Unique Node List).
• 9 października: Publiczne ujawnienie.

Poprawka nie przeszła przez standardowe głosowanie nad zmianą, lecz została wprowadzona jako bezpośrednia modyfikacja kodu w wersji 3.4.1 i zaczęła obowiązywać w miarę aktualizacji poszczególnych serwerów. Kod źródłowy opublikowano dopiero po wdrożeniu, co jest standardowym posunięciem mającym na celu uniknięcie dostarczenia atakującym „mapy”. Konto XRPL Operations ustaliło od tego czasu wersję 3.4.1 jako minimalną wymaganą wersję, dodając:

Nie znaleźliśmy żadnych dowodów na to, że ta luka została wykorzystana w jakiejkolwiek sieci publicznej.

W tej samej wersji naprawiono drugi błąd o niższym poziomie zagrożenia. Dotyczył on sposobu pakowania transakcji Batch, a jego poprawka znajduje się w poprawce fixBatchV1_2, która została wdrożona w sieci Mainnet 9 października wraz z BatchV1_1. Raport wskazuje, że również w tym przypadku nie doszło do utraty środków.

Ujawnienie tej informacji nastąpiło w trudnym tygodniu dla bezpieczeństwa kryptowalut, ponieważ straty związane z urządzeniami Ledger, o których informował serwis Bitcoin.com News, osiągnęły szacunkową wartość 93,4 mln dolarów. Wreszcie, wspierana przez Ripple firma Evernorth przygotowuje się do rozpoczęcia w poniedziałek notowań na giełdzie Nasdaq pod symbolem XRPN, dysponując w swoich zasobach około 473 milionami XRP. XRP rozszerza również swoją działalność na obszar zdecentralizowanych finansów (DeFi), a firma Firelight niedawno uruchomiła w sieci ochronę skarbca.