Wykorzystanie błędu Lightning było wyborem etycznym

To jest opinia redakcyjna Shinobi, samouka w przestrzeni Bitcoin i zorientowanego na technologię gospodarza podcastów Bitcoin.

Po raz drugi w ciągu mniej więcej miesiąca w btcd/LND wykorzystano błąd, który spowodował odejście od konsensusu w stosunku do Bitcoin Core. Po raz kolejny Burak był programistą, który uruchomił tę lukę – tym razem było to wyraźnie zamierzone – i po raz kolejny był to problem z kodem do analizowania transakcji Bitcoin powyżej warstwy konsensusu. Jak omawiałem w moim fragment poprzedniego błędu które uruchomił Burak, przed Taprootem istniały ograniczenia dotyczące wielkości skryptu i danych świadków w transakcji. Wraz z aktywacją Taproot limity te zostały usunięte, pozostawiając jedynie ograniczenia dotyczące samego limitu wielkości bloku, aby ograniczyć te części poszczególnych transakcji. Problem z ostatnim błędem polegał na tym, że pomimo tego, że kod konsensusu w btcd został poprawnie zaktualizowany, aby odzwierciedlić tę zmianę, kod obsługujący transmisję peer-to-peer – w tym analizowanie danych przed wysłaniem lub podczas odbioru – nie został poprawnie zaktualizowany. Zatem bloki i transakcje przetwarzania kodu, zanim faktycznie zostały przekazane do sprawdzenia pod kątem konsensusu, zawiodły dane, nigdy nie przekazały ich do logiki sprawdzania konsensusu, a dany blok nigdy nie został zweryfikowany.

Bardzo podobna sytuacja wydarzyła się tym razem. Kolejnym ograniczeniem w sekcji bazy kodu peer-to-peer było nieprawidłowe egzekwowanie ograniczenia danych świadka, ograniczając je do maksymalnie 1/8 rozmiaru bloku w przeciwieństwie do pełnego rozmiaru bloku. Burak stworzył m.in transakcja z danymi świadków tylko o jedną jednostkę masy powyżej ścisłego limitu i po raz kolejny zatrzymałem węzły btcd i LND na tej wysokości bloku. Ta transakcja była transakcją niestandardową, co oznacza, że ​​chociaż jest całkowicie poprawna zgodnie z regułami konsensusu, nie jest ważna zgodnie z domyślną polityką puli pamięci i dlatego węzły nie będą jej przekazywać przez sieć. Wydobycie go w blok jest całkowicie możliwe, ale jedynym sposobem, aby to zrobić, jest dostarczenie go bezpośrednio górnikowi, co zrobił Burak przy pomocy F2Pool.

To naprawdę pokazuje, że każdy fragment kodu, którego celem jest analizowanie i sprawdzanie poprawności danych Bitcoin, musi zostać poddany dokładnemu audytowi, aby upewnić się, że jest zgodny z tym, co zrobi Bitcoin Core. Nie ma znaczenia, czy ten kod jest silnikiem konsensusu dla implementacji węzła, czy tylko fragmentem kodu przekazującym transakcje dla węzła Lightning. Ten drugi błąd był dosłownie tuż nad tym z poprzedniego miesiąca w bazie kodu. Nie został nawet odkryty przez nikogo w Lightning Labs. AJ Towns poinformował o tym 11 października, dwa dni po wyzwoleniu pierwotnego błędu w wyniku transakcji multisig 998 z 999 Buraka. Został opublikowany publicznie na Githubie przez 10 godzin, zanim został usunięty. Następnie wprowadzono poprawkę, ale nie wydano jej, z zamiarem cichego załatania problemu w następnym wydaniu LND.

Jest to dość standardowa procedura w przypadku poważnej luki, szczególnie w przypadku projektu takiego jak Bitcoin Core, w którym taka luka może w rzeczywistości spowodować poważne uszkodzenie sieci/protokołu warstwy podstawowej. Jednak w tym konkretnym przypadku stwarzał on poważne ryzyko dla funduszy użytkowników LND, a biorąc pod uwagę fakt, że znajdował się dosłownie tuż obok poprzedniego błędu, który stwarzał takie samo ryzyko, szanse na jego wykrycie i wykorzystanie były bardzo wysokie, jak wykazał Burak. Nasuwa się pytanie, czy podejście „cichych łatek” jest właściwym rozwiązaniem w przypadku takich luk w zabezpieczeniach, które mogą narazić użytkowników na kradzież środków (ponieważ ich węzeł nie jest w stanie wykryć starych stanów kanałów i odpowiednio ich ukarać).

Jak wspomniałem w moim artykule na temat ostatniego błędu, gdyby złośliwy aktor znalazł błędy przed programistą mającym dobre intencje, mógłby taktycznie otworzyć nowe kanały dla podatnych na ataki węzłów, skierować całą zawartość tych kanałów z powrotem do siebie, a następnie wykorzystał błąd. Stamtąd mieliby te fundusze pod kontrolą, a także mogliby zamknąć kanał ze stanem początkowym, dosłownie podwajając swoje pieniądze. To, czego dokonał Burak, aktywnie wykorzystując ten problem w ironiczny sposób, w rzeczywistości uchroniło użytkowników LND przed takim atakiem.

Po wykorzystaniu tej metody użytkownicy byli podatni na takie ataki ze strony istniejących wcześniej rówieśników, z którymi mieli już otwarte kanały, ale nie można było już na nich celować za pomocą nowych kanałów. Ich węzły uległy zablokowaniu i nigdy nie rozpoznawały ani nie przetwarzały płatności za pośrednictwem kanałów, które ktoś próbował otworzyć po blokadzie, która zablokowała ich węzeł. Chociaż nie wyeliminowało to całkowicie ryzyka wykorzystania użytkowników, ograniczyło to ryzyko do osób, z którymi mieli już kanał. Działanie Buraka złagodziło to. Osobiście uważam, że tego typu działanie w odpowiedzi na błąd miało sens; ograniczyło szkody, uświadomiło użytkownikom ryzyko i doprowadziło do szybkiego załatania problemu.

Nie tylko LND miało na to wpływ. Płyn proces ustalania również został przerwany, wymagając aktualizacji od funkcjonariuszy federacji, aby to naprawić. Starsze wersje Rust Bitcoin miało to również wpływ, co spowodowało, że przeciągnięcie miało wpływ na niektóre eksploratory bloków i instancje elektrów (implementacja serwera zaplecza dla portfela Electrum). Teraz, z wyjątkiem powiązania Liquida, które ostatecznie udostępniło fundusze kluczom odzyskiwania awaryjnego przechowywanym przez Blockstream po wygaśnięciu blokady czasowej – i, realistycznie rzecz biorąc, w fabule filmu w stylu napadu, w którym Blockstream ukradł te fundusze, wszyscy wiedzą dokładnie, kogo ścigać – te inne problemy nigdy nie narażają niczyich funduszy na ryzyko. Ponadto Rust Bitcoin faktycznie załatał ten konkretny błąd w nowszych wersjach, co najwyraźniej nie doprowadziło do żadnej komunikacji z opiekunami innych baz kodu, aby podkreślić potencjał takich problemów. Dopiero aktywne wykorzystanie błędu w sieci szeroko ujawniło, że problem występuje w wielu bazach kodu.

Stwarza to pewne poważne problemy, jeśli chodzi o takie luki w oprogramowaniu warstwy 2 na Bitcoinie. Po pierwsze, powaga, z jaką te bazy kodów są kontrolowane pod kątem błędów bezpieczeństwa i sposób, w jaki jest to ustalane priorytetowo w porównaniu z integracją nowych funkcji. Myślę, że to bardzo wymowne, że bezpieczeństwo nie zawsze jest traktowane priorytetowo, biorąc pod uwagę, że ten drugi błąd nie został nawet znaleziony przez opiekunów bazy kodu, w której występował, mimo że dosłownie znajdował się tuż obok pierwszego błędu odkrytego w zeszłym miesiącu. Czy po jednym poważnym błędzie, który naraził fundusze użytkowników na ryzyko, nie przeprowadzono wewnętrznego audytu tej bazy kodu? Odkrycie tego zajęło komuś spoza projektu? Nie oznacza to, że ochrona środków użytkowników ma pierwszeństwo przed tworzeniem nowych funkcji w celu przyciągnięcia większej liczby użytkowników. Po drugie, fakt, że ten problem został już załatany w Rust Bitcoin, pokazuje brak komunikacji pomiędzy opiekunami różnych baz kodu w odniesieniu do takich błędów. Jest to całkiem zrozumiałe, ponieważ zupełnie różne bazy kodu nie powodują, że ktoś, kto znalazł błąd w jednym, od razu pomyśli: „Powinienem skontaktować się z innymi zespołami piszącymi podobne oprogramowanie w zupełnie innych językach programowania, aby ostrzec ich o możliwości wystąpienia takiego błędu”. Nie znajdujesz błędu w Windowsie i od razu myślisz o zgłoszeniu błędu do opiekunów jądra Linuksa. Bitcoin jako protokół rozproszonego konsensusu w sieci globalnej to jednak zupełnie inna bestia; może programiści Bitcoina powinni zacząć myśleć w ten sposób, jeśli chodzi o luki w oprogramowaniu Bitcoin. Zwłaszcza jeśli chodzi o analizowanie i interpretowanie danych w oparciu o konsensus.

Wreszcie, może jeśli chodzi o protokoły takie jak Lightning, które polegają na ciągłej obserwacji łańcucha bloków, aby móc reagować na stare stany kanałów w celu zachowania bezpieczeństwa, niezależne analizowanie i weryfikacja danych powinny zostać ograniczone do absolutnego minimum — jeśli nie zostały całkowicie usunięte i przekazane Bitcoin Core lub dane bezpośrednio z niego pochodzące. Core Lightning jest zaprojektowany w ten sposób, łącząc się z instancją Bitcoin Core i całkowicie od niej zależny w zakresie sprawdzania poprawności bloków i transakcji. Gdyby LND działało w ten sam sposób, żaden z tych błędów w btcd nie wpłynąłby na użytkowników LND w sposób narażający ich fundusze na ryzyko.

Niezależnie od tego, w jaki sposób zostanie to potraktowane – czy to całkowicie zlecić walidację na zewnątrz, czy po prostu zminimalizować walidację wewnętrzną i podejść do niej ze znacznie większą ostrożnością – ten incydent pokazuje, że coś musi się zmienić w podejściu do kwestii, w jaki sposób oprogramowanie warstwy 2 radzi sobie z interakcją z danymi związanymi z konsensusem. Po raz kolejny wszyscy mieli szczęście, że nie zostało to wykorzystane przez złośliwego aktora, ale przez programistę, który udowodnił, że ma rację. Biorąc to pod uwagę, Bitcoin nie może liczyć na szczęście ani nadzieję, że nie istnieją złośliwi aktorzy.

Programiści i użytkownicy powinni skupić się na ulepszaniu procesów, aby zapobiec ponownemu wystąpieniu takich incydentów, a nie na bawieniu się w obwinianie jak gorący ziemniak.

To jest gościnny post Shinobi. Wyrażone opinie są całkowicie ich własnymi i niekoniecznie odzwierciedlają opinie BTC Inc lub Bitcoin Magazine.