Zespół deweloperów XRP Ledger (XRPL) ujawnił 9 października lukę związaną z przepełnieniem liczby całkowitej, która w starannie skonstruowanych warunkach mogła pozwolić na stworzenie z niczego XRP możliwych do wydania. Poprawka została wydana w wersji xrpld 3.4.1 25 września, około dwa tygodnie przed publicznym ujawnieniem, a zespół poinformował, że nie znalazł dowodów na to, że luka została kiedykolwiek wykorzystana w sieci publicznej.

Szczegóły zostały przedstawione w raporcie z ujawnienia luki z 9 października.

Obliczenie płatności, które mogło stworzyć XRP z niczego

Raport opisuje lukę związaną z przepełnieniem liczby całkowitej w silniku płatności księgi. W starannie skonstruowanych warunkach płatność zużywająca wiele ofert z arkusza zleceń mogła zasilić konta w XRP, których nadawca faktycznie nie zapłacił. Arkusze zleceń to natywna struktura XRPL, część wbudowanej giełdy księgi, więc wadliwa arytmetyka znajduje się w kodzie, który stanowi podstawę handlu na księdze, a także płatności.

Każda pojedyncza oferta w transakcji mogła pozornie być ważna sama w sobie. Błąd pojawił się, gdy silnik dodał kwoty XRP ze wszystkich nich. Gdy suma przekroczyła maksymalny rozmiar liczby użytej do tego obliczenia, mogła się „zawinąć” do znacznie mniejszej wartości zamiast wygenerować błąd.

W takim scenariuszu silnik nadal zasilałby właścicieli ofert pełnymi kwotami XRP, obciążając kupującego jedynie „zawiniętą” sumą. Różnica stanowiła nowo stworzone XRP, które następnie można było przenosić, handlować nimi lub wysyłać na giełdę jak każde inne saldo.

Dlaczego luka była poważna

Atak nie wymagał dużego salda XRP. Atakujący mógł kontrolować konta składające oferty, opłacić niezbędne rezerwy kont i opłaty transakcyjne, anie rozproszyć stworzone XRP na tych kontach.

Luka dotyczyła arytmetyki płatności, a nie dostępu do portfela, pozostawiając klucze kont nietknięte. Jej wyzwolenie wymagało setek celowo wycenionych ofert oraz transakcji zaprojektowanej tak, aby zużyć je jednocześnie; zwykła płatność lub handel XRP nie zbliżyłby się do wartości potrzebnych do wywołania przepełnienia.

Dla księgi niewiele wad jest tak wrażliwych jak taka, która może wybić jednostki możliwe do wydania, ponieważ każde saldo zależy od tego, że nowe XRP wchodzą do obiegu wyłącznie zgodnie ze zdefiniowanymi zasadami sieci.

XRPL stwierdził, że nie znalazł dowodów na wykorzystanie luki w sieci publicznej i nie odnotowano naruszenia kluczy prywatnych, utraty środków ani awarii konsensusu. Wygląda na to, że luka istniała od momentu napisania obecnego silnika płatności w 2015 roku i pozostawała niewykryta, ponieważ normalna aktywność nigdy nie osiągnęła limitu arytmetycznego.

Istniejąca ochrona księgi przed nowo tworzonym XRP również opierała się na tym samym rodzaju dodawania. Mogła się „zawinąć” w taki sam sposób jak silnik płatności, sprawiając, że transakcja wydawała się normalna zamiast sygnalizować nieoczekiwany wzrost sald.

Dlaczego deweloperzy zastosowali awaryjne wdrożenie

Deweloperzy wydali poprawkę przepełnienia przed opublikowaniem jej szczegółów technicznych, ponieważ normalny harmonogram poprawek pozostawiłby znany exploit dostępnym przez tygodnie. Poprawka została wydana w wersji xrpld 3.4.1 25 września, a publiczne ujawnienie nastąpiło 9 października.

XRPL zwykle zmienia zasady transakcji poprzez poprawki (amendments). Walidatorzy najpierw aktualizują swoje oprogramowanie, a następnie utrzymują wymagane wsparcie przez ustalony okres, zanim nowa zasada zostanie aktywowana w tym samym punkcie księgi w całej sieci. Ten proces pozwala uniknąć sytuacji, w których różne serwery wyciągają różne wnioski dotyczące tej samej transakcji.

Czekanie na ten proces stworzyłoby w tym przypadku trudny problem. Ponieważ xrpld jest projektem open source, opublikowanie naprawy mogłoby pokazać atakującym, gdzie szukać, podczas gdy starsze oprogramowanie nadal akceptowałoby podatną ścieżkę transakcji. Zespół sprawił więc, że nowa kontrola przepełnienia zaczęła działać z chwilą aktualizacji pojedynczego serwera.

To szybsze podejście wiązało się z tymczasowym ryzykiem niekompatybilności: niezałatany serwer mógł zaakceptować transakcję exploit, którą zaktualizowany serwer odrzucił. Deweloperzy uznali to za mniej niebezpieczne niż dopuszczenie stworzonych XRP do rynku. Według raportu ponad 80% walidatorów na domyślnym UNL dokonało aktualizacji w dniu wydania wersji 3.4.1.

Ujawnienie objęło drugą, osobną lukę

Raport opisał także problem walidacji nadchodzącej funkcji Batch XRPL, która pozwala użytkownikom przesyłać kilka transakcji jako jedną całość. Luka mogła spowodować, że serwery działające na różnych wersjach oprogramowania miały odmienne zdanie co do źle sformułowanej transakcji Batch, przerywając walidację księgi lub psując aplikacje przetwarzające dane transakcyjne.

Lukę Batch wykryto, zanim funkcja trafiła na mainnet. W przeciwieństwie do tego problem przepełnienia dotyczył istniejącego kodu silnika płatności, dlatego jego poprawka nie mogła czekać na standardowy cykl aktywacji. Ponieważ sama funkcja jest wciąż nadchodząca, jej pojawienie się na mainnecie z już wdrożoną poprawką walidacji to ta część ujawnienia, która wciąż przed nami.

Raport pojawił się w momencie, gdy XRPL aktywował także nowe narzędzia kontroli kont dla firm. Zmiany dotyczą różnych części księgi, jednak obie zależą od tego, że operatorzy węzłów, dostawcy portfeli i deweloperzy stosują te same bieżące zasady.

Co muszą zrobić użytkownicy i operatorzy

Zwykli posiadacze XRP nie muszą przenosić środków, wymieniać portfela ani dokonywać wymiany tokenów. Aktualizacja dotyczy oprogramowania walidującego transakcje, a nie sald kont, kluczy portfela ani podaży XRP posiadanej przez użytkowników.

• Posiadacze XRP: Nie są wymagane żadne działania.
• Użytkownicy giełd: Śledź komunikaty platformy, jeśli giełda przeprowadza konserwację własnej infrastruktury XRPL.
• Operatorzy węzłów: Zaktualizuj do xrpld 3.4.1 lub nowszej wersji, aby pozostać w synchronizacji z siecią. Starsze serwery są obecnie zablokowane przez mechanizm poprawek po aktywacji poprawki Batch, co oznacza, że nie mogą dalej stosować bieżących zasad księgi, dopóki się nie zaktualizują.

Poprawka chroniła zasady podaży XRP, zanim zostały przetestowane

Ujawnienie pokazuje, jak blisko awarii integralności podaży znalazła się księga oraz dlaczego walidatorzy działali szybko. Luka została naprawiona, zanim jej szczegóły stały się publiczne, nie znaleziono żadnego exploitu, a silnik płatności korzysta teraz z kontroli zaprojektowanych tak, aby zatrzymać tę samą klasę błędów arytmetycznych, zanim dotrą do zwalidowanej księgi. Z zewnątrz pozostaje do obserwacji, jak szybko reszta sieci przejdzie na xrpld 3.4.1 lub nowszą wersję, biorąc pod uwagę, że niezałatane serwery są już zablokowane przez mechanizm poprawek i nie mogą śledzić bieżącej księgi.

Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady inwestycyjnej ani technicznej. Operatorzy węzłów powinni zapoznać się z aktualną dokumentacją wydań XRPL przed aktualizacją infrastruktury produkcyjnej.

Ten artykuł powstał na podstawie doniesień pierwotnie opublikowanych przez Coindoo.