Big Sleep: agent AI wykrywa podatność w SQLite zanim trafiła do release

Google Project Zero i DeepMind ogłosiły w październiku 2024 roku, że ich wspólny agent AI o nazwie Big Sleep jako pierwszy na świecie samodzielnie odkrył podatność bezpieczeństwa możliwą do wykorzystania w powszechnie stosowanym oprogramowaniu produkcyjnym — silniku baz danych SQLite. Błąd został zgłoszony twórcom SQLite i naprawiony tego samego dnia, zanim trafił do oficjalnego wydania.

Najważniejsze w skrócie

Big Sleep to agent AI ze współpracy Google Project Zero i DeepMind — ewolucja wcześniejszego projektu Naptime bazującego na Gemini 1.5 Pro
Odkryta podatność: exploitable stack buffer underflow w funkcji seriesBestIndex silnika SQLite — zgłoszona i naprawiona w październiku 2024
Błąd nie trafił do oficjalnego wydania SQLite — użytkownicy nie byli narażeni na atak
150 godzin CPU tradycyjnego fuzzingu AFL nie zdołało odnaleźć tego samego błędu
AI-powered OSS-Fuzz odkrył równolegle 26 podatności w open source, w tym CVE-2024-9143 w OpenSSL — bug obecny przez ok. 20 lat

Od Project Naptime do Big Sleep

Projekt Big Sleep wyrósł z wcześniejszego projektu badawczego Google Project Zero o nazwie Naptime, który oceniał, czy duże modele językowe mogą naśladować ofensywne techniki bezpieczeństwa. Gdy Naptime wykazał poprawę wyników na benchmarku CyberSecEval2, Project Zero połączył siły z Google DeepMind. Wynik tej współpracy — Big Sleep — to pełnoprawny agent zdolny do prowadzenia analizy wariantów podatności na realnym kodzie produkcyjnym.

Agent otrzymuje zestaw narzędzi: debugger, przeglądarkę kodu źródłowego, środowisko uruchomieniowe. Zadaniem jest analiza wariantów — czyli poszukiwanie podobnych błędów do tych wcześniej znalezionych i naprawionych. Model bazowy: Gemini 1.5 Pro.

Błąd, którego nie znalazł fuzzer

Odkryta podatność dotyczy funkcji seriesBestIndex w rozszerzeniu series.c silnika SQLite. Funkcja obsługuje zapytania z wirtualną tabelą generate_series. Problem polega na tym, że pole iColumn w strukturze sqlite3_index_constraint może przyjmować wartość -1 — specjalny marker dla ROWID. Funkcja nie obsługiwała tej wartości: odejmowała stałą SERIES_COLUMN_START, uzyskując -2, a następnie używała tej wartości jako indeksu tablicy aIdx[7], zapisując dane poniżej bufora na stosie.

W buildach produkcyjnych — w zależności od kompilatora i poziomu optymalizacji — prowadziło to do nadpisania wskaźnika pConstraint, co w następnej iteracji pętli skutkowało jego wyłuskaniem pod niepoprawny adres. Stan taki jest potencjalnie exploitable.

Agent odkrył błąd metodą analizy wariantów: dostał jako punkt startowy konkretny commit do repozytorium SQLite, przeanalizował zmiany, postawił hipotezy, wygenerował przypadki testowe, trafił na crash i zwrócił raport gotowy do zgłoszenia. W tej metodzie duże modele językowe (LLM) mają przewagę: przechowują rozległą wiedzę o znanych klasach podatności, co pozwala im szybciej postawić i zweryfikować hipotezy.

Tradycyjny fuzzer AFL przez 150 godzin CPU na tym samym celu nie znalazł błędu. Powodem jest natura podatności: typowe konfiguracje fuzzingu SQLite w OSS-Fuzz nie mają włączonego rozszerzenia generate_series. Pokrycie kodu to nie to samo co pokrycie wszystkich stanów — ta lekcja jest kluczowa dla zrozumienia, co AI wnosi do bezpieczeństwa.

Równoległy front: OSS-Fuzz z AI

W tym samym czasie zespół Google Open Source Security wdrożył AI do generowania celów fuzzujących w projekcie OSS-Fuzz. Pokrycie kodu wzrosło z 160 do 272 projektów C/C++ — dodano ponad 370 tysięcy linii nowego kodu objętego testami. Odkryto 26 nowych podatności, w tym CVE-2024-9143 w bibliotece OpenSSL — bug obecny w kodzie przez ok. dwie dekady, nieznajdowalny przez istniejące harnessy napisane przez ludzi.

W porównaniu do Big Sleep, podejście OSS-Fuzz jest inne: LLM generuje harnessy fuzzujące, naprawia błędy kompilacji, triage'uje awarie, ale nie prowadzi pełnej analizy wariantów. Big Sleep działa jak autonomiczny agent AI zdolny do samodzielnego planowania kroków badania. Oba narzędzia mają różne mocne strony: fuzzing jest skuteczniejszy dla szerokiego przeszukiwania przestrzeni wejść, Big Sleep — dla głębszej analizy logiki kodu.

Dlaczego to ważne?

Odkrycie Big Sleep wyznacza konkretny punkt odniesienia: agent AI po raz pierwszy samodzielnie znalazł podatność możliwą do wykorzystania w szeroko stosowanym oprogramowaniu produkcyjnym. Nie był to proof-of-concept na syntetycznym benchmarku, lecz rzeczywisty błąd w SQLite — silniku wbudowanym w miliardy urządzeń i aplikacji, od przeglądarek przez systemy embedded po backendy chmurowe.

Dla obrońców oznacza to potencjalne narzędzie do wyprzedzenia atakujących: jeśli podatność zostanie znaleziona przez AI zanim trafi do release'u, atakujący nie mają co eksploitować. Analiza wariantów to coś, w czym LLM mają naturalną przewagę nad fuzzingiem — reagują na semantykę kodu, a nie tylko na pokrycie gałęzi. Ograniczenia są jednak wyraźne: Big Sleep jest w fazie badawczej, a jeden znaleziony błąd to obiecujący wynik, nie gwarancja powszechnej skuteczności.

Co dalej?

Zespół Big Sleep pracuje nad piątym krokiem pipeline'u: automatycznym generowaniem poprawek (patch generation) — nie było gotowe w momencie publikacji wyników w listopadzie 2024
OSS-Fuzz planuje rozbudowę o pełny pipeline agentowy z dostępem LLM do narzędzi debuggera, celem automatyzacji triage'u i bezpośredniego raportowania do maintainerów projektów
SQLite i OpenSSL jako projekty o krytycznym znaczeniu dla globalnej infrastruktury sieciowej pozostają priorytetowymi celami dla AI-assisted security research