Home » Błąd klienta Ethereum proof-of-stake złapany i załatany bez incydentów

Błąd klienta Ethereum proof-of-stake złapany i załatany bez incydentów

by Patricia

Deweloperzy Ethereum odkryli błąd, który mógł prowadzić do utknięcia łańcuchów EVM z powodu błędu nadmiaru gazu w kliencie Besu.

Deweloperzy Ethereum zidentyfikowali błąd w kliencie Besu Ethereum, który mógł doprowadzić do „niepowodzenia konsensusu w sieciach z wieloma implementacjami EVM.”

Gary Schulte zgłosił problem do repozytorium Hyperledger GitHub, a znalazł go Martin Holst Swende. Przyjmuje się, że „żadne sieci produkcyjne nie mają transakcji, które wywołałyby tę awarię. „

Błąd zidentyfikowany podczas przeglądu kodu The Merge

Swende udokumentował, że znalazł błąd podczas „robienia jakiegoś TheMerge”. W odpowiedzi nanaszego dziennikarza, Swende stwierdził, że użytkownicy uruchamiający węzeł Besu utknęliby i „nie byliby w stanie śledzić łańcucha kanonu”. Co więcej, każda „zdominowana przez Besu sieć mogła zostać zatrzymana w miejscu. „

Klient Besu jest drugim najpopularniejszym klientem w sieci Ethereum za Geth. Według danych dostępnych za pośrednictwem ethernodes.org, klient Besu jest używany przez 7,81% klientów sieci głównej Ethereum.

Wrażliwe wersje klienta Besu

Wersja 22.7.1 klienta Besu zawiera poprawkę zapewniającą, że „nadmiar gazu nie będzie przydzielany do wewnętrznych wywołań transakcji oraz poprawiającą błędy nadmiaru gazu.”

Wersje wcześniejsze niż 22.1.3 również „zapobiegną błędnemu wykonaniu”, jednak Ethereum mainnet wymaga innych funkcji dostępnych tylko w późniejszych wersjach. Wersje klienta 22.4.0 do 22.7.0 są obecnie uważane za podatne na błąd gazu.

W związku z tym użytkownicy klienta Besu na mainnecie muszą zaktualizować go do załatanej wersji.

Impact and resolution

Danno Ferrin stworzył pełne opisy problemu w artykule Hackmd opublikowanym 21 września. Analiza Ferrin’a stwierdzała, że

„Błąd w obsłudze niepodpisanych danych jako podpisanych danych prawidłowo zakodowany smart kontrakt może stworzyć wywołanie funkcji, która zwróci więcej gazu niż zostało przekazane. „

Dalsze informacje techniczne dotyczące błędu można znaleźć w poście Ferrin’a. Najważniejsze jest jednak to, że błąd został rozwiązany bez żadnych problemów w sieci Ethereum. Aby zły aktor mógł złośliwie wykorzystać błąd, musiałby działać w precyzyjny sposób.

„Aby podnieść ten błąd do rangi błędu typu chain-halting, potrzebne było celowo spreparowane wywołanie, obejmujące pewne interakcje z zasadą EIP-150 „all but one 64th” i zarezerwowanie części dostępnego gazu dla wywołującego kontraktu. „

Jeśli błąd nie został znaleziony, każdy łańcuch z dużym udziałem klienta Besu mógł doświadczyć inteligentnego kontraktu „nieskończonej pętli”, dzięki której kontrakt „naprawdę wykonywałby się bez końca.”

Ferrin stwierdził, że fuzzing umożliwił programistom zidentyfikowanie i załatanie błędu bez problemu. Fuzzing jest metodą używaną przez programistów, „która polega na dostarczaniu nieważnych, nieoczekiwanych lub losowych danych jako wejść do programu komputerowego. „

„Największą lekcją zademonstrowaną przez ten exploit jest to, że porównanie danych śladowych w egzekucji fuzzingu wyłapuje więcej błędów niż samo porównanie wyników końcowych. „

Błąd związany z nadmiarem gazu stał się nie wydarzeniem dzięki staranności deweloperów Ethereum poświęcających się ochronie sieci. Jednak potencjalne szkody, które mógł spowodować, pokazują złożoność wykonania scalenia bez problemów.

Błąd został załatany w wersji 22.7.1 przy użyciu „innej metody konwersji, która „zaciśnie” wartości przepełnienia do maksymalnych oczekiwanych wartości, unikając problemów z podpisanym tłumaczeniem.” Ferrin skomentował, że użytkownicy korzystający z węzłów w zasięgu podatności powinni zaktualizować je do najnowszej wersji.

Related Posts

Leave a Comment