Deweloperzy Ethereum usunęli dwie oddzielne luki, które mogły zagrozić depozytom walidatorów i nagrodom za bloki: jedną związaną ze słabymi certyfikatami stron internetowych oraz drugą, ukrytą w wersji roboczej zasad nadchodzącej aktualizacji sieci o nazwie Glamsterdam. Teku, klient consensus, oraz Besu, klient execution, wydały łaty eliminujące to ryzyko. Węzły Ethereum uruchamiają jednocześnie klienta consensus i klienta execution, co oznacza, że obie warstwy stosu węzła wymagały tego samego czyszczenia certyfikatów.

Teku wydał wersję 26.10.3 w dniu 27 października, dzień po tym, jak Besu wydał wersję 26.10.2 w dniu 26 października. Oba wydania usuwają dotknięte urzędy certyfikacji z obrazów Docker używanych do uruchamiania węzłów Ethereum, zgodnie ze stroną wydań Teku.

Wykryto słabe klucze certyfikatów

Badacze odkryli 17 października, że osiem certyfikatów pośrednich wydanych przez indyjską firmę eMudhra opierało się na kluczach prywatnych, które atakujący mogli wyliczyć z publicznie dostępnych informacji. Posiadając te klucze, atakujący mogli wystawiać certyfikaty dla fałszywych usług. eMudhra odwołał certyfikaty, ale niektóre instalacje Javy nadal je ufundowały, ponieważ Java domyślnie nie sprawdza odwołania certyfikatów. Zarówno Teku, jak i Besu są napisane w Javie — w ten sposób słabość dotarła do operacji węzłów Ethereum.

Odkrycie nastąpiło w tym samym tygodniu, w którym Google zapowiedział system bezpieczeństwa kryptowalutowego depozytowania zaprojektowany tak, aby dzielić klucze prywatne między oddzielne środowiska.

Jak mogło dojść do przekierowania opłat walidatorów

Luka w certyfikatach miała znaczenie, ponieważ walidatory zależą od połączeń z usługami zewnętrznymi. Atakujący zdolny przechwycić takie połączenie mógł podszyć się pod usługę po drugiej stronie. Teku ostrzegł, że sfałszowane połączenie ze zdalnym węzłem mogło spowodować zapłatę opłat za bloki na adres kontrolowany przez atakującego. Usługi zewnętrznego podpisywania stanowiły dodatkowe ryzyko w dotkniętych konfiguracjach, ponieważ atakujący mógł uzyskać podpisy przekierowujące nagrody.

„Domyślny węzeł Teku na mainnecie nie jest dotknięty i nie wymaga żadnych działań” — oświadczył Teku. Zespół klienta nie odnotował żadnego znanego wykorzystania luki.

Poprawione zasady depozytów Glamsterdam

W oddzielnym działaniu deweloperzy zrewidowali proponowane zasady Glamsterdam po tym, jak badacz avsetsin zidentyfikował błąd routingu depozytów. Odroczyli również aktualizację testnetu Hoodi, która była zaplanowana na 26 października.

Według wcześniejszego projektu builder i walidator dzielący jeden klucz publiczny mogli spowodować, że depozyty stakingowe trafią na konto buildera. Glamsterdam ma na celu oddzielenie budowania bloków od walidacji, a zrewidowany projekt sortuje oczekujące depozyty według poświadczeń wypłat (withdrawal credentials), odróżniając depozyty walidatorów od depozytów builderów.

Zespoły klientów początkowo odrzuciły poprawkę 19 października z powodu braku porozumienia. Deweloperzy następnie dodali testy i scalili zrewidowane zasady 26 października.

Różne dalsze kroki dla operatorów węzłów

Poprawka Glamsterdam została wprowadzona do specyfikacji Ethereum, ale zespoły oprogramowania muszą ją jeszcze wdrożyć. Glamsterdam był wcześniej uruchamiany na teściecie Sepolia, a Hoodi czeka na nową datę aktywacji.

Operatorzy uruchamiający Teku lub Besu poza Docker muszą oddzielnie zaktualizować Javę. Ryzyko certyfikatów obejmowało płatności pochodzące z opłat gazowych Ethereum, takie jak opłaty priorytetowe wypłacane walidatorom, a nie zwykłe salda portfeli użytkowników. Teku zalecił użytkownikom nieobsługiwanego Java 26 przejście na Java 25.

Łaty certyfikatów usuwają problem z dotkniętych obrazów Docker, podczas gdy poprawka Glamsterdam czeka na wdrożenie w całym ekosystemie klientów Ethereum.