Polygon ujawnia luki bezpieczeństwa załatane przez hard forki Austin i Kyoto
Najważniejsze informacje
- •Polygon ujawnił luki w klientach Bor i Heimdall dopiero po wdrożeniu poprawek za pomocą hard forków Austin i Kyoto, stosując podejście skoordynowanego ujawniania.
- •Najpoważniejsza luka dotyczyła Heimdalla, gdzie spreparowana transakcja mogła zmusić walidatorów do nadmiernej pracy obliczeniowej i zakłócić działanie sieci.
- •Hard fork Austin rozwiązał dwa odrębne ryzyka denial-of-service w Borze, które mogły spowolnić przetwarzanie bloków lub spowodować awarię węzłów.
- •Polygon oświadczył, że nie ma dowodów na wykorzystanie luk w mainnecie.
- •Węzły z nieaktualnymi klientami muszą zaktualizować oprogramowanie do Bor v2.10.0 i Heimdall v0.11.0, ponieważ starsze wersje wypadły z konsensusu.

Polygon publicznie ujawnił zestaw wcześniej niejawnych luk bezpieczeństwa, które mogły zakłócić działanie jego sieci proof-of-stake. Firma ujawniła wady dopiero po wdrożeniu poprawek za pomocą hard forków Austin i Kyoto.
Luki dotyczyły klientów Polygon – Bor i Heimdall – i obejmowały ryzyko ataków typu denial-of-service, wyczerpywanie zasobów walidatorów oraz słabości w przetwarzaniu checkpointów i milestone'ów. Polygon oświadczył, że nie znalazł dowodów na wykorzystanie tych wad w mainnecie. Bor pełni funkcję klienta wykonawczego produkującego bloki w Polygon PoS, natomiast Heimdall odpowiada za checkpointy i koordynację walidatorów, dlatego luki w każdym z tych komponentów bezpośrednio wpływają na to, jak łańcuch osiąga i zapisuje konsensus.
Poprawki wdrożone przed ujawnieniem
Polygon załatał luki przed opublikowaniem ich szczegółów technicznych. Takie podejście pozwoliło programistom przetestować poprawki i aktywować je bez uprzedzania potencjalnych atakujących. Jest to zgodne z modelem skoordynowanego ujawniania, powszechnie stosowanym w branży oprogramowania i przez duże projekty blockchain, w którym szczegóły techniczne są zatajane do momentu szerokiego wdrożenia poprawek, aby wyniki badań nie stały się instrukcjami ataku.
Najpoważniejszy problem dotyczył Heimdalla, gdzie specjalnie spreparowana transakcja mogła zmusić walidatorów do wykonywania nadmiernej pracy obliczeniowej. Taka aktywność mogła wywrzeć znaczną presję na walidatory i potencjalnie zakłócić działanie sieci.
Hard fork Austin rozwiązał dwa odrębne ryzyka denial-of-service w Borze. Te wady mogły spowolnić przetwarzanie bloków lub spowodować awarię dotkniętych węzłów.
Polygon podał, że aktualizacje zostały przetestowane przed aktywacją w mainnecie, a ujawnienie nastąpiło dopiero po pomyślnym wdrożeniu poprawek, co zmniejszyło ryzyko wykorzystania publicznie znanych szczegółów luk przeciwko niezałatanym węzłom. To nie pierwszy przypadek, gdy Polygon po cichu obsłużył krytyczne wady przed ich ujawnieniem: projekt wcześniej ujawnił załatany krytyczny błąd w Borze dopiero po tym, jak poprawka działała w mainnecie, tworząc wzorzec praktyki bezpieczeństwa „najpierw łataj, potem ujawniaj”.
Operatorzy węzłów muszą dokonać aktualizacji
Hard forki stworzyły także natychmiastowy wymóg dla operatorów węzłów. Węzły działające na starszych wersjach klientów po przekroczeniu odpowiednich wysokości aktywacji wypadły z konsensusu i muszą przeprowadzić aktualizację, aby ponownie połączyć się z kanoniczną siecią Polygon.
Polygon wymaga wersji Bor v2.10.0 dla węzłów Polygon PoS, a walidatorzy i pełne węzły muszą dodatkowo uruchamiać Heimdall v0.11.0. Obie wersje są już aktywne w mainnecie.
Ujawnienie podkreśla znaczenie skoordynowanych działań w zakresie bezpieczeństwa dla sieci blockchain. Chociaż Polygon uniknął w tym przypadku potwierdzonego ataku w mainnecie, luki te mogły zagrozić dostępności sieci, gdyby atakujący odkryli i wykorzystali je pierwsi.
Aktualizacje Austin i Kyoto pełniły zatem podwójną rolę: jako poprawki bezpieczeństwa oraz jako krytyczne kroki konserwacyjne infrastruktury walidatorów Polygon. Dla operatorów węzłów i dostawców infrastruktury takie przypadki są przypomnieniem, aby uważnie śledzić informacje o wydaniach klientów i wysokości aktywacji, ponieważ pominięcie obowiązkowego hard forka skutkuje natychmiastowym odłączeniem od konsensusu, a nie jedynie pogorszeniem wydajności węzła.