Wpis XRPL naprawia krytyczną lukę przed mainnetem, ale aplikacje klienckie pozostają zagrożone pojawił się na BitcoinEthereumNews.com.
Walidatorzy XRP Ledger (XRPL) umieścili BatchV1_1 na warunkowej ścieżce aktywacji o 14:06:41 UTC 29 września, zamieniając bliski incydent bezpieczeństwa w test na żywo procesu zmian sieci i otaczającego go oprogramowania. 22 września xrpldashboard pokazał 30 z 35 zaufanych walidatorów popierających zmianę, powyżej wyświetlanego progu 28 głosów. Większość po raz pierwszy pojawiła się w księdze 15 września. Zgodnie z zasadami zmian XRPL poparcie musi utrzymywać się powyżej 80% przez dwa tygodnie. Spadek do 80% lub mniej kończy okres większości, więc data aktywacji pozostaje warunkowa. 29 września to pierwszy produkcyjny test tego, czy proces walidatorów XRPL, implementacja referencyjna i ekosystem klientów przekształciły niebezpieczną lukę przed mainnetem w użyteczną infrastrukturę transakcji atomowych. Zapora walidatorów zadziałała przed mainnetem Oryginalna zmiana Batch nigdy nie została aktywowana w mainnecie XRP Ledger. W lutym badacze odkryli krytyczną lukę w autoryzacji, gdy zmiana była jeszcze w fazie głosowania, a walidatorom zalecono zagłosowanie przeciwko niej. Oficjalne ujawnienie podatności przez XRPL Labs stwierdza, że żadne środki nie były zagrożone. Luka znajdowała się w pętli, która sprawdzała konta autoryzujące partię. Jeśli kod napotkał sygnatariusza nowo utworzonego konta, którego klucz pasował do tego konta, natychmiast zwracał sukces, zamiast kontynuować przez pozostałych sygnatariuszy. Atakujący mógł umieścić tego prawidłowego sygnatariusza na pierwszym miejscu, a następnie dodać sfałszowany wpis rzekomo autoryzujący konto ofiary. Gdyby zmiana weszła w życie, niesprawdzona transakcja ofiary mogłaby zostać wykonana bez kluczy ofiary. Odpowiedź XRPL przyszła w dwóch etapach. Wersja 3.1.1 oznaczyła oryginalne zmiany Batch i fixBatchInnerSigs jako nieobsługiwane, blokując ich aktywację. BatchV1_1 później zastąpiła je przepisaną ścieżką autoryzacji i dodatkowymi zabezpieczeniami. Ten epizod był błędem wychwyconym na granicy między wydaniem oprogramowania a aktywacją protokołu. Ostateczna specyfikacja XLS-56 Fundacji XRPL teraz…