Bitcoin Core ujawnił trzy luki w zabezpieczeniach wykryte podczas skanowania kodu z użyciem sztucznej inteligencji. Jedna z nich pozwalała zdalnie doprowadzić do awarii węzłów działających na Windowsie, macOS lub BSD. Błędy zostały już załatane, a ich opis opublikowano zgodnie z nowymi zasadami projektu.
Zdalne przeciążenie węzła
Najpoważniejsza z ujawnionych podatności umożliwiała komputerowi połączonemu z węzłem Bitcoin Core wysyłanie tak dużej ilości danych, że urządzeniu zaczynało brakować pamięci. W efekcie węzeł mógł się zawiesić lub przestać działać. Problem wykryto 23 października, a poprawki udostępniono cztery dni później.
Węzły są istotną częścią sieci Bitcoin: weryfikują transakcje i przekazują je dalej. Bitcoin Core to oprogramowanie używane przez większość z nich, dlatego jego bezpieczeństwo ma znaczenie dla działania całego ekosystemu.
AI zmienia zasady ujawniania błędów
Wszystkie trzy problemy wskazał automatyczny skan kodu wspierany przez duży model językowy. Zanim informacje trafiły do zespołu bezpieczeństwa, każde znalezisko sprawdził człowiek.
Zmieniła się też polityka ujawniania luk. Wcześniej podatności o średnim poziomie ryzyka mogły pozostawać niepubliczne nawet przez rok, by dać operatorom czas na aktualizację. Od 22 października błędy uznane za łatwe do wykrycia — również przy użyciu AI — mają być naprawiane i opisywane publicznie możliwie szybko.
Komentarz autora: Wykorzystanie AI może przyspieszyć wykrywanie błędów, ale nie zastępuje weryfikacji przez człowieka. Szybkie ujawnianie podatności daje operatorom jasny sygnał, że powinni zadbać o aktualizacje. Warto też pamiętać, że poprawka nie zawsze eliminuje ryzyko w każdej konfiguracji.
Przeczytaj także: Five Eyes ostrzega przed wykorzystywaniem AI do cyberataków.
Pozostałe wykryte podatności
Drugi błąd pozwalał podłączonemu węzłowi udawać, że korzysta ze starszej wersji protokołu, a następnie spowalniać działanie urządzenia. Wiadomości gromadziły się w jego pamięci: według opisu podatności mogło przybywać ich do 2 MB na godzinę dla każdego połączenia przychodzącego i do 5 MB dla wychodzącego.
Trzecia luka, oceniona jako mało poważna, wiązała się z plikami wykorzystywanymi podczas reorganizacji łańcucha bloków. Górnik mógł przygotować bloki powodujące przepełnienie tych plików. Na komputerach 64-bitowych przeprowadzenie takiego ataku wymagałoby około miesiąca całej produkcji bloków w sieci, ale na systemach Windows i 32-bitowych węzeł mógł ulec awarii.
Sama aktualizacja nie usuwa ryzyka dla wszystkich konfiguracji. Według opublikowanego ostrzeżenia podatne pozostają niektóre węzły 32-bitowe oraz urządzenia zapisujące bloki na starszych nośnikach sformatowanych w systemie FAT32; ponowne uruchomienie takiego węzła nie rozwiązuje problemu.
Twórcy Bitcoin Core zapowiedzieli ponadto, że za około dwa tygodnie ujawnią szczegóły trzech kolejnych luk o średnim i wysokim poziomie zagrożenia, naprawionych w wersji 30.0.
To pokazuje, że nawet w tak „prostym” kodzie jak node software można siekac sobie DoS-a na pamięci. Najbardziej mnie bawi, że problem wychodzi przy AI-skanowaniu, a nie ręcznym audycie. Dla operatorów na Windowsie i BSD to raczej nie jest teoria, tylko realny crash pod obciążeniem.
Trochę słabo, że nadal są konfiguracje 32-bit i FAT32 trzymane przy życiu, bo potem wychodzą takie kwiatki. Zmiana polityki ujawniania też ma sens – skoro łatki są gotowe, to nie ma co kisić problemu po cichu przez rok. W krypto i tak każdy i tak prędzej czy później zrobi update, jeśli mu zależy.
Z technicznego punktu widzenia to nie wygląda na exploit „na koniec świata”, tylko na klasyczny resource exhaustion. Ale i tak wystarczy, żeby postawić kilka węzłów na kolana, a to w sieci P2P już robi problem. Swoją drogą ciekawe, ile takich bugów siedzi jeszcze w kodzie, którego nikt nie tykał od lat.
Mam węzeł na Linuxie, ale i tak czytam takie rzeczy z lekkim niepokojem, bo backupy robię na starszym NAS-ie z FAT32 i to już brzmi średnio. Nie wiem, czy autorzy dobrze jasno napisali, które scenariusze są naprawdę podatne, bo dla zwykłego usera to trochę chaos. Jak ktoś ma 32-bit, to bym już nie ryzykował z tym na produkcji.
Najbardziej uderza to, że podłączony peer mógł symulować starszy protokół i przez to zatykać pamięć wiadomościami. To nie jest jakiś egzotyczny edge case, tylko rzecz do wywołania w zwykłej topologii sieciowej. Btw, 2 MB na godzinę per incoming connection niby nie brzmi strasznie, ale przy kilku sąsiadach i długim uptime robi się z tego syf.
Znowu wychodzi, że „bezpieczny” software to w praktyce ciągłe łatanie dziur. Trochę mnie zastanawia, czy publiczne opisywanie tak szybko nie daje więcej paliwa osobom szukającym crashy niż realnie pomaga operatorom. Ale z drugiej strony, jak łatka już jest, to ukrywanie tego też nie ma większego sensu.
To chyba pierwszy raz, kiedy AI faktycznie zrobiła coś pożytecznego w security, a nie tylko pisala marketingowe slajdy. I dobrze, bo ręczne szukanie takich błędów w dużym projekcie pewnie trwałoby wieki. Szkoda tylko, że dalej zostają stare 32-bitowe instalacje, bo to już bardziej problem utrzymania niż samej podatności.