Dyrektor inżynierii Ripple, Vijay Khanna, wezwał 2 sierpnia operatorów węzłów XRP Ledger do zainstalowania wersji xrpld 3.2.1 po tym, jak programiści zaobserwowali 31 lipca zalew manifestów walidatorów.
Podsumowanie
- Zalew manifestów z 31 lipca skłonił do wydania xrpld 3.2.1, podczas gdy XRP Ledger przez cały czas normalnie zamykał księgi.
- Cztery zabezpieczenia ograniczają teraz rozmiar manifestu, partie wiadomości, udostępnianie wychodzące i wzrost pamięci podręcznej nieznanych kluczy w całej sieci.
- Operatorzy powinni dokonać aktualizacji, zweryfikować działanie xrpld, a następnie ponownie uruchomić, aby bezpiecznie wyczyścić utrwalone manifesty.
Poprawka ogranicza sposób, w jaki węzły przetwarzają, przechowują i udostępniają dane otrzymane od nieznanych tożsamości walidatorów.
XRP Ledger kontynuował normalne zamykanie ksiąg podczas tego zdarzenia, zgodnie z XRP Ledger Operations. Dostępne dowody wskazują zatem na obciążenie zasobów węzłów i komunikacji peer-to-peer, a nie na potwierdzoną utratę środków, zmienione transakcje lub awarię konsensusu księgi. Programiści nie opublikowali identyfikatora CVE ani szacunkowych strat finansowych związanych z incydentem.
XRPL 3.2.1 ogranicza drogę zalewu manifestów
Manifesty walidatorów to podpisane kryptograficznie rekordy, które łączą stałą tożsamość główną walidatora z tymczasowym kluczem używanym do codziennych wiadomości walidacyjnych. Gdy operatorzy rotują te tymczasowe klucze, publikują nowy manifest podpisany kluczem głównym, aby inne węzły mogły zweryfikować zmianę.
Przed poprawką węzły mogły akceptować, buforować i ponownie rozgłaszać poprawnie skonstruowane manifesty związane z kluczami walidatorów, których nie rozpoznawały. Atakujący mógł wykorzystać to zachowanie, tworząc wiele nieznanych tożsamości i zmuszając rówieśników do zużywania pamięci, przestrzeni dyskowej, przepustowości i mocy obliczeniowej na przetwarzanie tych danych. Publiczny zapis kodu opisuje tę wadę jako problem z propagacją manifestów.
Oficjalne wydanie xrpld 3.2.1 jest datowane na 31 lipca i zostało opublikowane jako najnowsze podpisane wydanie na początku 1 sierpnia. Zawiera sześć commitów w 13 zmienionych plikach, w tym cztery commity bezpośrednio ograniczające obsługę niezaufanych manifestów.
Cztery zabezpieczenia zmniejszają ryzyko wyczerpania zasobów
Pierwsze zabezpieczenie odrzuca zbyt duży manifest walidatora, zanim węzeł w pełni go zdekoduje. Zmniejsza to pracę przetwarzania, którą atakujący może wywołać, wysyłając pojedyncze obiekty większe niż oczekuje oprogramowanie.
Drugie ogranicza liczbę niezaufanych manifestów przenoszonych w jednej wiadomości sieciowej. Limit obowiązuje, gdy węzły odbierają dane i gdy przygotowują wiadomości manifestów dla rówieśników. Zbyt duże partie są odrzucane bez automatycznego rozłączania niezałatanego rówieśnika, co pomaga zaktualizowanym i starszym węzłom pozostać połączonymi podczas wdrażania.
Trzecia zmiana ogranicza liczbę nieznanych tożsamości walidatorów przechowywanych w pamięci podręcznej manifestów węzła. Ostateczny kod ustawia maksimum na 100. Po osiągnięciu tej pojemności oprogramowanie odrzuca manifesty powiązane z nowymi niewymienionymi kluczami, kontynuując przetwarzanie zaufanych lub wcześniej rozpoznanych walidatorów.
Poprawka zmienia również sposób przechowywania i propagowania informacji o niezaufanych manifestach. Dane zaufanych walidatorów pozostają dostępne, ponieważ ograniczenia dotyczą niezweryfikowanych plotek o rówieśnikach, a nie manifestów od skonfigurowanych lub zatwierdzonych walidatorów. To rozróżnienie pozwala na normalną rotację kluczy walidatorów, jednocześnie blokując niekontrolowany wzrost pamięci podręcznej.
Operatorzy węzłów muszą wykonać drugi restart
Khanna zalecił walidatorom i innym operatorom infrastruktury aktualizację do wersji 3.2.1 „tak szybko, jak to możliwe”. Jego instrukcje przewidują normalną aktualizację oprogramowania, po której następuje odczekanie jednej do dwóch minut i sprawdzenie, czy xrpld działa. Operatorzy powinni następnie ponownie uruchomić usługę.
Drugi restart jest ważny dla węzłów, które mogły zachować nieznane manifesty przed zainstalowaniem poprawki. Aktualizacja zmienia przyszłe postępowanie, a ponowne uruchomienie poprawionego serwera pomaga zapewnić, że stare dane w pamięci lub wcześniej zachowane dane nie będą nadal wpływać na operacje.
Operatorzy mogą również musieć potwierdzić, że ich systemy ufają bieżącemu kluczowi podpisywania pakietów Ripple. Notatki wydania stwierdzają, że Ripple zmienił klucz GPG używany do podpisywania pakietów xrpld 18 lutego. Istniejące instalacje, które nie zaufały kluczowi zastępczemu, mogą nie otrzymywać automatycznych aktualizacji pomyślnie.
Aktualizacja dotyczy dostawców infrastruktury, a nie zwykłych posiadaczy XRP. Użytkownicy nie muszą przenosić XRP, zmieniać kluczy portfela ani tworzyć nowych kont z powodu problemu z manifestami. Giełdy, opiekunowie, backendy portfeli, dostawcy danych i firmy prowadzące własne serwery XRPL powinny zamiast tego potwierdzić wersje swoich węzłów i status restartu.
Analiza pośmiertna określi zakres incydentu
XRP Ledger Operations poinformowało, że techniczna „analiza pośmiertna wkrótce nastąpi”. Według stanu na 2 sierpnia projekt nie opublikował tego raportu, więc tożsamość nadawcy, wolumen przesłanych manifestów i dokładne wykorzystanie zasobów w dotkniętych węzłach pozostają nieujawnione.
Raport powinien również wyjaśnić, kiedy programiści po raz pierwszy wykryli tę aktywność, czy jakiekolwiek węzły stały się niedostępne i jak szybko operatorzy przyjęli wersję 3.2.1. Chociaż księgi nadal się zamykały, powolne wdrażanie poprawek może pozostawić poszczególne serwery narażone na ponowne zalewanie, nawet gdy wspólna księga pozostaje operacyjna.
Poprawka pojawia się wkrótce po większym wydaniu wersji 3.2.0 XRPL. To wydanie, opublikowane 15 czerwca, zmieniło nazwę serwera referencyjnego z rippled na xrpld i wprowadziło zmiany infrastrukturalne, które wymagały od operatorów aktualizacji oprogramowania i konfiguracji usług.
Jak wcześniej informowano, wersja 3.2.0 początkowo rozprzestrzeniała się szybciej wśród walidatorów niż w szerszej sieci węzłów. Zalew manifestów dodaje nowy powód dla pozostałych operatorów, aby przejść poza to wydanie i zainstalować poprawkę.
Tymczasem w powiązanych doniesieniach, David Schwartz przeniósł swoją infrastrukturę XRPL do wersji 3.2.0, gdy programiści przygotowywali sieć do nowej nazwy serwera i funkcji protokołu. Wcześniej, jak donosił crypto.news, operatorzy węzłów również stanęli w obliczu terminu wersji 3.1.3 związanego z aktywacją poprawki.
Następne zweryfikowane aktualizacje to obiecana analiza pośmiertna i świeże dane dotyczące wdrażania oprogramowania. Do tego czasu potwierdzona odpowiedź pozostaje ograniczona do wydania 3.2.1, jego czterech kontroli manifestów i prośby o dokończenie przez operatorów procesu aktualizacji i restartu.
