Dziesięć tysięcy gwiazdek i jeden commit

14 lipca xAI opublikowało kod źródłowy Grok Build na licencji Apache 2.0, a do dzisiejszego ranka repozytorium zebrało ponad dziesięć tysięcy gwiazdek. Wydanie było następstwem testu na poziomie ruchu sieciowego, który wykazał, że wersja 0.2.93 narzędzia wysyła śledzone repozytorium wraz z jego pełną historią git spakowaną jako bundle do chmurowej przestrzeni dyskowej kontrolowanej przez xAI, w tym repozytorium, którego asystent miał polecenie nie czytać. Pisaliśmy o tym ustaleniu 14 lipca, a zalecenie brzmiało wtedy: zrotować każdy sekret, jaki narzędzie kiedykolwiek widziało. To zalecenie pozostaje aktualne.

Opublikowanie kodu wygląda na najmocniejszą możliwą odpowiedź na tego rodzaju ustalenie. To ruch, na jaki decyduje się organizacja inżynierska przekonana, że zapis ją oczyszcza, i właśnie tak jest odbierany. Użyteczne pytanie nie brzmi więc, czy xAI słusznie opublikowało kod. Jest węższe i bardziej praktyczne: gdybyś dziś sięgnął do tego repozytorium, żeby upewnić się, co narzędzie robiło na twoich maszynach, co dałoby się faktycznie ustalić?

Jak się okazuje, bardzo niewiele, a powody są raczej strukturalne niż złowieszcze. Repozytorium zawiera jeden commit, którego autorem jest bot, z 16 lipca, godzina 05:46 UTC, z komunikatem mówiącym, że publikuje on harness i TUI jako open source. Jeden commit oznacza brak historii. Nie ma stanu wcześniejszego, nie ma diffa, nie ma sekwencji zmian, nie ma czego porównywać. Dziesięć tysięcy gwiazdek pod repozytorium bez historii to dziesięć tysięcy osób popierających gest.

Czego repozytorium nie jest w stanie powiedzieć

Zacznij od jedynego pytania, które to ustalenie faktycznie postawiło: dokąd trafił kod? Wysyłki szły do bucketa Google Cloud Storage, którego nazwa figuruje w dostarczonej binarce. W opublikowanym źródle ta nazwa nie występuje. Jest odczytywana ze zmiennej środowiskowej ustawianej w czasie kompilacji i rozwiązywanej podczas budowania binarki. Cel podaje ten, kto kompiluje wydanie, a źródło milczy o tym, dokąd kierowana była dostarczona kompilacja. Opublikowany kod nie odpowiada na to pytanie w żadną stronę.

Następnie przyjrzyj się funkcji, która wykonywała wysyłkę. Nadal tam jest, w crate shell, i już nic nie robi. Przyjmuje swoje parametry, oznacza je jako nieużywane, czeka na kanale, wyrzuca wynik i zwraca niepowodzenie z adnotacją, że wysyłka stanu sesji jest niedostępna. Ciało funkcji usunięto, a otoczenie zostało: miejsca wywołania są nienaruszone, manifest wciąż wymienia zależności, pomocnicze funkcje storage nadal są kompilowane. To, co można przeczytać, to szkielet mechanizmu z wyjętym mechanizmem.

To już drugi raz, gdy poprawkę wprowadzono w miejscu, którego nie możesz sprawdzić. Pierwotne wysyłki zatrzymano 13 lipca flagą po stronie serwera, a nie wydaniem klienta, i to była najostrzejsza część pierwszej historii: binarka, którą twój zespół przejrzał i przypiął, nigdy nie była tym, co decydowało o tym, co opuszcza maszynę. Teraz kod jest publiczny, cel nadal jest parametrem podawanym przy budowaniu, a przełącznik nadal siedzi na serwerze. Powierzchnia, którą da się audytować, i powierzchnia, która decyduje, nie zbliżyły się do siebie ani o krok.

Cztery pliki przeniesione, jeden nie dotarł

Jest jeszcze jeden szczegół i trzeba go przedstawić ostrożnie, bo łatwo odczytać go za mocno. Ciągi znaków wewnątrz dostarczonej binarki 0.2.93 wskazują crate o nazwie xai-data-collector, zawierający pięć plików źródłowych: klienta storage, warstwę cloud storage, kolejkę, obserwator circuit breakera oraz moduł śledzący dostęp do plików. Opublikowane repozytorium nie zawiera crate o takiej nazwie. Ten sam zestaw plików znajduje się w crate o nazwie xai-file-utils i cztery z pięciu mają swoje odpowiedniki. Piątego, czyli modułu śledzącego dostęp do plików, w opublikowanym źródle w ogóle nie ma.

Sedno tkwi w tym, co to ustala, a czego nie ustala. Nie ustala to intencji. Zmiana nazwy crate z takiej, która opisuje zbieranie danych, na taką, która opisuje obsługę plików, to dokładnie to, co zespół robi przy porządkowaniu wydania, a usunięcie modułu, który nie jest już z niczym połączony, to zwykłe sprzątanie. Nie ma tu żadnych dowodów na ukrywanie czegokolwiek i niczego takiego nie zarzucamy. Warto też odnotować asymetrię w samym materiale dowodowym: strona binarki opiera się na ekstrakcji ciągów znaków wykonanej przez podmiot trzeci, natomiast stronę źródła może zweryfikować każdy, kto sklonuje repozytorium.

Ustala natomiast, że to wydanie nie może pełnić roli zapisu. Komponentu, którego nazwa najbardziej wprost opisuje śledzenie dostępu użytkownika do plików, brakuje, jego rodzeństwo jest obecne pod inną nazwą, a nie ma historii commitów, w której dałoby się przyjrzeć któremukolwiek z tych faktów. Niewinne wyjaśnienia i te obciążające dają identyczne repozytorium. Na tym polega problem z traktowaniem publikacji jako dowodu: działa to tylko wtedy, gdy artefakt potrafi rozróżnić jedno od drugiego, a ten nie potrafi.

Twierdzenie, którego nigdy nie postawiono

Trzeba oddać badaczowi sprawiedliwość, bo to dyscyplina po tamtej stronie tej historii sprawia, że się ona broni. Analizę na poziomie ruchu sieciowego przeprowadzono z użyciem przechwytującego proxy wobec przypiętej binarki, na jednorazowym repozytorium zasianym plikami kanarkowymi, i jest ona odtwarzalna: istnieje publiczny harness i każdy może go uruchomić. Pomiar był jednoznaczny. Repozytorium o rozmiarze dwunastu gigabajtów wygenerowało 5,10 gibibajta ruchu wysyłkowego wobec 192 kilobajtów faktycznej rozmowy z modelem, co daje stosunek bliski dwudziestu ośmiu tysiącom do jednego. Plik kanarkowy, którego asystent miał nie czytać, wyszedł z przechwyconego bundle nienaruszony.

A potem badacz spisał to, czego test nie udowodnił. Że wysyłanie to nie trenowanie, ponieważ zmierzono wyłącznie transmisję. Że jedno przechwycenie przy trzech gigabajtach nie zostało zachowane. Że wcześniejszy wniosek był błędny, ponieważ pomiar sieci ograniczony do procesu pominął wysyłki idące bezpośrednio na adresy Google, i że ten wniosek został wycofany. Ustalenie, które publikuje własne ograniczenia i własne sprostowanie, to ustalenie, z którego da się korzystać.

Zestaw to z odpowiedziami. xAI oświadczyło, że głęboko zależy mu na prywatności, że szanuje wybór klienta i że w przypadku zespołów korzystających z zerowej retencji danych żadne dane śladów ani kodu nigdy nie są przechowywane. Elon Musk powiedział, że wszystkie dane użytkowników wysłane do tej pory zostaną całkowicie i bez reszty usunięte i że nie pozostanie absolutnie nic. Te twierdzenia mogą być prawdziwe. Żadnego z nich nie da się jednak sprawdzić, a usunięcia nie da się zweryfikować z zewnątrz. Wzór powtarza się w całym tym epizodzie: twierdzenia, które da się przetestować, pochodziły od osoby dysponującej proxy, a te, których przetestować się nie da, pochodziły od dostawcy.

Trzy pytania, zanim uznasz sprawę za załatwioną

Wniosek, który da się uogólnić, nie ma nic wspólnego z xAI i przyda się ponownie jeszcze w tym miesiącu. Otwieranie kodu stało się standardową odpowiedzią na ustalenie dotyczące bezpieczeństwa i jest odpowiedzią dobrą wtedy, gdy artefakt niesie ze sobą dowody. Nie jest nią automatycznie. Kiedy więc dostawca odpowiada na ustalenie dotyczące twoich danych publikacją kodu, postaw mu trzy pytania, zanim zamkniesz zgłoszenie.

Czy widzę historię? Spłaszczony commit początkowy to fotografia, a nie zapis. Jeśli repozytorium zaczyna się w dniu publikacji, nie może pokazać, co się zmieniło, a przedmiotem badania jest właśnie zmiana. Czy opublikowany artefakt odpowiada dostarczonej binarce? Jeśli którekolwiek istotne zachowanie jest ustawiane przy budowaniu albo trzymane na serwerze, źródło jest opisem pewnej możliwości, a nie tego, co działało na twoich maszynach. Czy kod zawiera komponent wskazany w ustaleniu? Jeśli konkretnej rzeczy, którą znaleziono, nie ma w repozytorium, jej brak nie jest odpowiedzią, bez względu na to, co go spowodowało.

Nic z tego nie przemawia za zamykaniem kodu i nic z tego nie jest oskarżeniem. Przemawia natomiast za rozróżnieniem, którego twój proces zakupowy prawdopodobnie jeszcze nie stosuje: publikacja jest aktem ujawnienia, a audyt jest procesem, który prowadzi do wniosku. Jedno nie zastępuje drugiego, nie są nawet bliskimi krewnymi, a dostawca, który zrobił to pierwsze, nie zrobił tego drugiego. Zespoły traktujące link do repozytorium jako zamknięcie sprawy popełniają błąd kategorialny, a to rodzaj błędu, który widać dopiero z perspektywy czasu, po kolejnym ustaleniu.

Czytaj dalej: Żadne laboratorium AI nie przekroczyło C+ w bezpieczeństwie  |  Prefect kupił drugi orkiestrator z waszej listy