Bitcoin Core zrewidował swoją politykę ujawniania luk bezpieczeństwa, aby przyspieszyć poprawki dla podatności, które duże modele językowe mogą odkryć przy minimalnym wysiłku, eliminując wielomiesięczne embarga, jakimi wcześniej były objęte takie błędy.

Opiekunowie projektu scalili zmianę w polityce bezpieczeństwa w czwartek. Deweloper Chaincode Labs Antoine Poinsot, autor propozycji, ogłosił ją tego samego dnia w wiadomości na liście mailingowej Bitcoin Development Mailing List.

„Niedawno zaobserwowaliśmy wzrost liczby zgłoszeń dotyczących podatności bezpieczeństwa, które można łatwo (ponownie) odkryć” — napisał Poinsot. „Wynika to w dużej mierze z tego, że LLM drastycznie obniżyły próg znajdowania pewnych klas problemów lub identyfikowania ukrytych poprawek.”

Rewizja czyni łatwość odkrycia — a nie tylko wagę błędu — czynnikiem wpływającym na tempo, w jakim oprogramowanie obsługujące większość węzłów Bitcoin otrzymuje publiczną poprawkę.

Jak działała dotychczasowa polityka

W poprzednich ramach Bitcoin Core — oprogramowanie działające na większości węzłów sieci Bitcoin — klasyfikował każde zgłoszoną podatność według wagi i dostosowywał do niej termin ujawnienia. Błędy o niskiej wadze były ujawniane dwa tygodnie po wydaniu kolejnej wersji głównej.

Problemy o średniej i wysokiej wadze pozostawały pod embargiem do dwóch tygodni po zakończeniu wsparcia ostatniej dotkniętej wersji — okres, który mógł sięgać roku.

Długie terminy miały dać operatorom węzłów, z których wielu aktualizuje oprogramowanie powoli, czas na przejście na łatane wersje przed upublicznieniem szczegółów. W praktyce oznaczało to, że poprawki nie były wydawane dla starszych, utrzymywanych wersji i pojawiały się dopiero z kolejną wersją główną.

Poinsot argumentował, że ten kompromis zawodzi w przypadku błęd łatwych do ponownego odkrycia. „Okres embarga przynosi niewiele korzyści, a opóźnia udostępnienie poprawionej wersji” — czytamy w polityce.

Co się zmienia

Podczas wstępnej analizy Bitcoin Core może teraz oznaczyć podatność jako „łatwo wykrywalną” — kategoria ta obejmuje, zgodnie z definicją w polityce, problemy, które można znaleźć „przy minimalnym wysiłku, na przykład za pomocą prostego prompta LLM”. Etykieta może być też stosowana do błędów odkrytych innymi sposobami.

W przypadku takich problemów projekt zastosuje backport poprawki do każdej utrzymywanej wersji głównej, wyda wersje poprawkowe tak szybko, jak to możliwe i opublikuje biuletyn bezpieczeństwa z częścią szczegółów w tym samym czasie co oprogramowanie z poprawką. Poinsot przyznał, że takie poprawki będą miały mniej czasu na testy przed dotarciem do użytkowników. Dla operatorów starszych, utrzymywanych wersji oznacza to, że poprawki trafią do nich jako wydania poprawkowe, a nie dopiero z kolejną wersją główną, a szczegóły zostaną opublikowane w momencie wydania poprawki.

Podatności spoza tej kategorii zachowują dotychczasowy harmonogram oparty na wadze błędu. Krytyczne błędy — te, które mogłyby umożliwić kradzież monet na poziomie protokołu, zawyżenie podaży lub trwałe rozgałęzienie łańcucha — pozostają poza standardową polityką i będą rozpatrywane indywidualnie.

Deweloper Antoine Riard postulował możliwość wydania poprawki bez biuletynu i wstrzymania szczegółów w przypadkach rozpatrywanych indywidualnie. Poinsot odmówił, pisząc, że ostrzeganie użytkowników bez podania szczegółów „mogłoby niepotrzebnie zwiększyć ryzyko”, skłaniając do pospiesznej migracji użytkowników, których w przeciwnym razie problem by nie dotyczył.

Lato raportów generowanych przez AI

Zmiana polityki następuje po miesiącach wzmożonej presji na open-source'owe projekty Bitcoin. Pod koniec lipca ochotnicza grupa 16 deweloperów znana jako Bitcoin Red Team uruchomiła modele AI na 390 repozytoriach bitcoin w ciągu około jednego dnia i zarejestrowała 4 962 ustalenia, w tym 85 ocenionych jako krytyczne.

W ciągu kilku dni luka w BTCPay Server, którą grupa zgłosiła prywatnie, została wykorzystana na działających serwerach merchantów, prowadząc do opróżnienia węzłów Lightning.

W sierpniu deweloperzy Core Lightning nakazali operatorom aktualizację lub rozłączenie, po tym jak raporty dotyczące projektu wygenerowane przez AI okazały się trafne.

Działania Red Team nastąpiły po wykorzystaniu podatności w sprzętowym portfelu Coldcard, w którym atakujący opróżnili 594 BTC w 25 minut 30 lipca. Straty w czterech przeprowadzeniach zbliżyły się do 114 milionów dolarów.

To, jak często będzie stosowana etykieta „łatwo wykrywalna” — i jak szybko pojawią się poprawki — będzie widoczne w przyszłych biuletynach i wydaniach poprawkowych Bitcoin Core.

Źródło: Bitcoin Magazine | Autor: Micah Zimmerman