Jeden z klientów konsensusu Ethereum scalił poprawkę dla ataku zatrucia pamięci podręcznej kluczy publicznych walidatorów, zgodnie z pull requestem na GitHubie. Łatka rozwiązuje lukę w zabezpieczeniach związaną z forkiem Gloas, która mogła powodować, że niektóre węzły odrzucały prawidłowe podpisy z powodu błędu w globalnej pamięci podręcznej kluczy publicznych.
Gloas to część warstwy konsensusu nadchodzącej aktualizacji Glamsterdam.
Trzy depozyty, dwa łańcuchy
Problem leży w mechanizmie, w którym klient przechowuje klucze publiczne walidatorów i ich indeksy w globalnej pamięci podręcznej.
Technicznie rzecz biorąc, depozyty, które zostały już sfinalizowane, powinny dawać tych samych walidatorów w każdym łańcuchu, choć na granicy forka sprawa wygląda inaczej.
Atakujący potrzebuje 3 oczekujących depozytów tuż przed forkiem. Pierwszy z nich to duże uzupełnienie dla istniejącego walidatora. Pozostałe dwa to nowe klucze: A z poświadczeniami buildera i B ze zwykłymi poświadczeniami walidatora.
W łańcuchu kanonicznym uzupełnienie zużywa rotację salda, więc A i B są przetwarzane po forku. A staje się builderem, a B zajmuje następny indeks walidatora.
Po stronie łańcucha atakującego uzupełniony walidator zostaje ukarany (slashing) przed forkiem, a jego depozyt jest pomijany. Prowadzi to do tego, że A jest przetwarzany wcześniej, zasadniczo zajmując indeks B.
Błędna pamięć podręczna zakładała, że oba łańcuchy wygenerują tych samych walidatorów, i globalnie zaimportowała klucz A.
W momencie forka dotknięte węzły odrzuciłyby wszystkie prawidłowe podpisy od B w łańcuchu kanonicznym i odłączyłyby się od niego.
Realistycznie rzecz biorąc, atak jest dość skomplikowany, ponieważ wymaga slashingu w odpowiednim momencie oraz łańcucha bocznego, więc jest mało prawdopodobne, aby wydarzył się przypadkowo.
Co zmienia poprawka?
Zgodnie z PR, poprawka polega na dodawaniu kluczy do globalnej pamięci podręcznej kluczy publicznych dopiero po sfinalizowaniu ich epoki kwalifikowalności do aktywacji.
Nowa struktura HeadPubkeys łączy również klucze ze stanu head i z globalnej pamięci podręcznej, aby węzły nie pomijały kluczy, jeśli łańcuch zostanie sfinalizowany bez nowych bloków.
Czy inne klienty konsensusu miały podobny problem, pozostaje do potwierdzenia. Innymi słowy, im bliżej Glamsterdam, tym więcej przypadków brzegowych wokół granicy forka muszą wychwycić deweloperzy.
