Spis treści
Deweloperzy Ethereum zidentyfikowany błąd w kliencie Besu Ethereum, który mógł doprowadzić do „błędu konsensusu w sieciach z wieloma implementacjami EVM”.
Gary Schulte zgłosił problem do repozytorium Hyperledger GitHub i został znaleziony przez Martina Holsta Swende. Rozumie się, że „żadne sieci produkcyjne nie mają transakcji, które wywołałyby tę awarię”.
Błąd zidentyfikowany podczas przeglądu kodu Merge
Swende udokumentował, że znalazł błąd, gdy „robię coś #ethereum fuzzing w przygotowaniu do #Połączenie”. W odpowiedzi na dziennikarza CryptoSlate, Swende stwierdził, że użytkownicy korzystający z węzła Besu utknęliby i „nie byliby w stanie śledzić łańcucha kanonów”. Co więcej, każda „sieć zdominowana przez besu mogła zostać zatrzymana”.
Utknęliby, nie mogąc podążać za łańcuchem kanonów. I/lub każda sieć zdominowana przez besu (nie-eth-mainnet) mogła zostać zatrzymana w jej śladach.
— MH (((Swende))) (@mhswende) 27 września 2022
The Besu klient jest drugim najpopularniejszym klientem w sieci Ethereum po Geth. Według danych dostępnych za pośrednictwem ethernodes.org, klient Besu jest używany przez 7,81% klientów sieci Ethereum.
Podatne wersje klienta Besu
Wersja 22.7.1 klienta Besu zawiera poprawkę zapewniającą, że „nadmiar gazu nie zostanie przydzielony do wewnętrznych wywołań transakcji i korygowania błędów nadmiaru gazu”.
Wersje wcześniejsze niż 22.1.3 również „zapobiegają nieprawidłowemu wykonaniu”, jednak sieć główna Ethereum wymaga innych funkcji dostępnych tylko w późniejszych wersjach. Klient wersje 22.4.0 do 22.7.0 są obecnie uważane za podatne na błąd gazu.
W rezultacie użytkownicy klienta Besu w sieci głównej muszą uaktualnić do wersji załatanej.
Wpływ i rozdzielczość
Danno Ferrin stworzył pełny opis problemu w artykule Hackmd opublikowanym 21 września. Analiza Ferrina wykazała, że
„Błąd w obsłudze niepodpisanych danych jako danych podpisanych, a prawidłowo zakodowany inteligentny kontrakt może stworzyć wywołanie funkcji, które zwróci więcej gazu niż zostało przekazane”.
Dalsze informacje techniczne dotyczące błędu można znaleźć w Stanowisko Ferrina. Jednak głównym wnioskiem jest to, że błąd został rozwiązany bez żadnych problemów w sieci głównej Ethereum. Aby zły aktor złośliwie wykorzystał błąd, musiałby działać w precyzyjny sposób.
„Aby podnieść to do poziomu błędu zatrzymującego łańcuch, potrzebne było celowo spreparowane wezwanie, obejmujące pewne interakcje z EIP-150 „wszystko oprócz jednej 64.” i zarezerwowanie części dostępnego gazu dla umowy telefonicznej.”
Gdyby błąd nie został znaleziony, każdy łańcuch z dużym udziałem klienta Besu mógłby doświadczyć inteligentnej „nieskończonej pętli” kontraktu, dzięki której umowa „naprawdę byłaby wykonywana na zawsze”.
Ferrin stwierdził, że fuzzing umożliwił programistom zidentyfikowanie i naprawienie błędu bez problemów. Fuzzing to metoda stosowana przez programistów, „która polega na dostarczaniu nieprawidłowych, nieoczekiwanych lub losowych danych jako danych wejściowych do programu komputerowego”.
„Największą lekcją, jaką wykazał ten exploit, jest to, że porównanie danych śledzenia w rozmytym wykonaniu wychwytuje więcej błędów niż po prostu porównywanie wyników końcowych”.
Błąd związany z nadmiarem gazu stał się wydarzeniem nieistniejącym ze względu na staranność deweloperów Ethereum, którzy poświęcili się ochronie sieci. Jednak potencjalne szkody, jakie mogło to spowodować, pokazują złożoność wykonania scalenia bez problemów.
Błąd został załatany w wersji 22.7.1 przy użyciu „a inna metoda konwersji które „zaciśnie” wartości przepełnienia do maksymalnych oczekiwanych wartości, unikając problemów z podpisanym tłumaczeniem. Ferrin skomentował, że użytkownicy uruchamiający węzły w zakresie podatności powinni zaktualizować do najnowszej wersji.
