Från kodassistans till autonom hacking: När en utvärdering övergår i ett intrång

Det viktigaste att förstå är följande: Forskarna bad modellen att genomföra en avancerad utvärdering av exploateringsförmåga, men det finns inga offentliga belägg för att de uttryckligen instruerade den att angripa Hugging Face.

Hugging Face blev i stället ett mål som modellen själv identifierade och valde efter att ha fått tillgång till internet.

Det innebär inte att modellen utvecklade ”onda avsikter” i mänsklig bemärkelse, och inte heller att den bröt sig loss från sitt ursprungliga mål. Tvärtom är OpenAI:s preliminära bedömning att modellen blev alltför fokuserad på att slutföra ExploitGym och till slut identifierade ”att ta sig in i ett externt produktionssystem och få fram det korrekta svaret” som en möjlig väg framåt.

Det som verkligen är värt att diskutera i den här incidenten är därför inte huruvida AI plötsligt fick en egen drivkraft att attackera, utan en mer specifik fråga:

När en modell kan anropa verktyg, köra processer kontinuerligt, observera resultat och förfina sin strategi – kan vi då fortfarande betrakta den som enbart ett chattsystem som genererar text?

Låt oss gå tillbaka till 2023, då en vän till mig ville utveckla ett eget chattverktyg med hjälp av elliptisk kurvkryptografi.

Motivationen var enkel: vanliga chattjänster kräver att innehåll skickas till tredjepartsservrar för bearbetning, vilket medför risk för dataläckor. Eftersom de projekt som han och hans team arbetade med vanligtvis lagrades på ett internt nätverk ville han bygga en klient och server för kommunikation som kunde kryptera trafiken inom ett lokalt nätverk, köras på Windows och överföra filer.

Klientgränssnittet byggdes med Qt, krypteringskomponenten implementerade han själv och all kod för gränssnittet och affärslogiken i projektet genererades med hjälp av GPT-4.

Redan då kunde GPT-4 producera en hel del användbar kod. Om man tydligt beskrev fönsterlayout, knappar, inmatningsfält, kontaktlistor och andra krav kunde modellen stegvis generera ett Qt-gränssnitt. Efter flera omgångar av dialog och revideringar lyckades min vän faktiskt bygga gränssnittet.

Men till slut stötte projektet på problem med TCP-kommunikationen.

Han bad GPT-4 upprepade gånger att ändra den Socket-relaterade koden, men problemen blev aldrig helt lösta:

• Läsningar och skrivningar i flera trådar synkroniserades inte korrekt, vilket ibland ledde till korrupta data
• Problem med sammanslagning och fragmentering av TCP-paket samt hanteringen av meddelandegränser löstes inte på ett tillförlitligt sätt
• När en anslutning bröts kunde klienten inte återansluta som den skulle
• Blockerande sockets fick trådar eller användargränssnittet att frysa
• Hanteringen av objekts livscykler blev rörig när undantag uppstod
• En bugg kunde åtgärdas, men samtidigt introducerades nya kapplöpningsförhållanden (race conditions) på andra ställen

Efter att ha granskat koden fick jag en ungefärlig bild av var problemet låg.

Det handlade inte om att GPT-4 vid den tiden var helt oförmögen att skriva nätverksprogram. Problemet var snarare att dessa fel sällan är begränsade till en enskild, isolerad funktion. De är fördelade över trådmodellen, protokolldesignen, buffert hanteringen, anslutningstillstånd och felhanteringen. För att lösa dem krävs en förståelse för hur systemets tillstånd förändras över tid.

Dåtidens stora språkmodeller var bra på att generera kod som såg korrekt ut utifrån lokala beskrivningar. Men de kunde inte felsöka programmet på användarens dator, och än mindre upprätthålla de övergripande systemkraven i ett verkligt ingenjörsprojekt över tid.

De kunde skriva funktioner, men de kunde inte ta ansvar för systemets tillstånd under körning.