Google twierdzi, że jeden z jego modeli sztucznej inteligencji jest pierwszym tego rodzaju, który wykrył lukę w zabezpieczeniach pamięci, w szczególności możliwe do wykorzystania niedopełnienie bufora stosu w SQLite, które następnie naprawiono przed oficjalnym wydaniem błędnego kodu.
Narzędzie do polowania na błędy oparte na LLM firmy Chocolate Factory, nazwane Big Sleep, to wynik współpracy Google Project Zero i DeepMind. Mówi się, że to oprogramowanie jest ewolucją wcześniejszego projektu Naptime, ogłoszonego w czerwcu.
SQLite to silnik bazy danych o otwartym kodzie źródłowym i niedopełnienie bufora stosu wrażliwość mógłby pozwolić atakującemu na spowodowanie awarii lub nawet wykonanie dowolnego kodu. Mówiąc dokładniej, awaria lub wykonanie kodu nastąpi w pliku wykonywalnym SQLite (nie w bibliotece) z powodu przypadkowego użycia magicznej wartości -1 w pewnym momencie jako indeksu tablicy. W kodzie znajduje się funkcja Assert(), która przechwytuje użycie -1 jako indeksu, ale w kompilacjach wydań ta kontrola na poziomie debugowania zostanie usunięta.
W związku z tym złoczyńca może spowodować awarię lub spowodować wykonanie kodu na komputerze ofiary, być może poprzez wywołanie błędu złego indeksu za pomocą złośliwie spreparowanej bazy danych udostępnionej temu użytkownikowi lub poprzez zastrzyk SQL. Nawet pracownicy Google przyznają, że wykorzystanie tej luki nie jest łatwe, należy więc mieć świadomość, że tak naprawdę nie chodzi tu o powagę luki – chodzi o to, że internetowy gigant wierzy, że jego sztuczna inteligencja zdobyła pierwszy punkt.
Powiedziano nam, że fuzzowanie – wprowadzanie losowych i/lub starannie spreparowanych danych do oprogramowania w celu wykrycia błędów, które można wykorzystać – nie rozwiązało problemu.
LLM jednak to zrobił. Według Google jest to pierwszy raz, kiedy agent sztucznej inteligencji znalazł wcześniej nieznaną, możliwą do wykorzystania lukę w zakresie bezpieczeństwa pamięci w powszechnie używanym oprogramowaniu w świecie rzeczywistym. Po tym, jak Big Sleep zarejestrował błąd na początku października i otrzymał polecenie wykonania szeregu zatwierdzeń w kodzie źródłowym projektu, programiści SQLite naprawiłem to tego samego dnia. Tym samym usterka została usunięta przed oficjalną premierą.
„Uważamy, że ta praca ma ogromny potencjał obronny” – zespół Big Sleep zapiał w piśmie z 1 listopada. „Fuzzing znacząco pomógł, ale potrzebujemy podejścia, które pomoże obrońcom znaleźć błędy, które są trudne (lub niemożliwe) do znalezienia poprzez fuzzowanie, i mamy nadzieję, że sztuczna inteligencja może zmniejszyć tę lukę”.
Warto zauważyć, że w październiku firma Protect AI z siedzibą w Seattle ogłoszony bezpłatne narzędzie typu open source, które według niego może znajdować luki dnia zerowego w bazach kodu Pythona przy pomocy modelu Claude AI firmy Anthropic.
Narzędzie to nazywa się Vulnhuntr i według jego twórców znalazło kilkanaście błędów dnia zerowego w dużych projektach Pythona typu open source.
Według Google te dwa narzędzia mają różne cele. „Naszym twierdzeniem w poście na blogu jest to, że Big Sleep odkrył pierwszą nieznaną możliwość wykorzystania kwestia bezpieczeństwa pamięci w powszechnie używanym oprogramowaniu w świecie rzeczywistym” – powiedział rzecznik Google Rejestrz dodanym naszym podkreśleniem. „Python LLM znajduje różne typy błędów niezwiązanych z bezpieczeństwem pamięci”.
Program Big Sleep, będący wciąż na etapie badań, wykorzystywał do tej pory małe programy ze znanymi lukami w zabezpieczeniach do oceny swojej zdolności wykrywania błędów. Był to jego pierwszy eksperyment w świecie rzeczywistym.
Na potrzeby testu zespół zebrał kilka ostatnich zatwierdzeń w repozytorium SQLite. Po ręcznym usunięciu trywialnych zmian dotyczących wyłącznie dokumentów „następnie dostosowaliśmy monit, aby zapewnić agentowi zarówno komunikat zatwierdzenia, jak i informację różnicową dotyczącą zmiany, i poprosiliśmy agenta o przejrzenie bieżącego repozytorium (w GŁOWA) w przypadku powiązanych problemów, które mogły nie zostać naprawione” – napisał zespół.
LLM, oparty na Gemini 1.5 Pro, ostatecznie znalazł błąd, który był luźno powiązany ze zmianami w zatwierdzeniu nasion (1976c3f7). „Nie jest to rzadkością w przypadku ręcznej analizy wariantów – zrozumienie jednego błędu w bazie kodu często prowadzi badacza do innych problemów” – wyjaśnili pracownicy Google.
W swoim raporcie zespół Big Sleep szczegółowo opisał także „najważniejsze” kroki podjęte przez agenta w celu oceny kodu, znalezienia luki, awarii systemu, a następnie sporządzenia analizy pierwotnej przyczyny.
„Chcemy jednak powtórzyć, że są to wyniki wysoce eksperymentalne” – napisali. „Stanowisko zespołu Big Sleep jest takie, że obecnie prawdopodobne jest, że fuzzer ukierunkowany na konkretny cel będzie co najmniej równie skuteczny (w znajdowaniu luk w zabezpieczeniach)”. ®
