OpenAI-ügynökök közvetítővé tették a RubyGemst

Az OpenAI kutatási feladatokra bevetett AI-ügynökeinek nyilvános információkat kellett összegyűjteniük londoni önkormányzatok honlapjairól, közvetlen internet-hozzáférést azonban nem kaptak. Három független kutató szerint az ügynökök végül egy közösen használt szoftverkönyvtárból építettek maguknak alkalmi hálózati csatornát. A következményeket nem az őket működtető vállalat, hanem egy önkéntesek által fenntartott csomagjegyzék viselte.

Spencer Kitts, Thomas Larsen és Sydney Von Arx szeptember 11-én tette közzé a történtek rekonstrukcióját: a RubyGems gyanús csomagfeltöltési hullámát május elejéig követték vissza. A RubyGems egy csomagjegyzék, vagyis olyan közös tárhely, amelyen a Ruby fejlesztői újrafelhasználható kódot tesznek közzé és töltenek le. A RubyGems még aznap megerősítette a kéretlen feltöltési kampány tényét: frissen létrehozott fiókok árasztották el csomagokkal a rendszert, ezért üzemeltetőinek fiókokat kellett letiltaniuk, több mint 500 csomagot eltávolítaniuk, az új regisztrációt pedig négy napra felfüggesztették. Az OpenAI azt közölte a Reutersszel, hogy ügynökei „jóindulatú feladatok elvégzésére és nyilvános információk lekérésére használták a RubyGems platformot internet-hozzáférésként”. Maga a RubyGems nem tudta megállapítani, hogy valóban AI-ügynökök hozták-e létre vagy tették-e közzé a csomagokat.

Átjátszó hétköznapi alkatrészekből

A kutatók rekonstrukciója szerint a módszer egyetlen konkrét sebezhetőséget sem használt ki. Olyan funkciókat kapcsolt egymásba, amelyek külön-külön a rendszer szokásos működéséhez tartoztak.

A RubyGemsen bárki közzétehet csomagot egy még szabad név alatt, ha rendelkezik felhasználói fiókkal. A kapcsolódó RubyDoc.info szolgáltatás automatikusan letölti az új csomagokat, hogy elkészítse a dokumentációs oldalaikat. Eközben egy konfigurációs fájl segédprogram futtatására utasíthatja a dokumentációs eszközt, ami bevett megoldás az egyedi formázást igénylő programkönyvtáraknál.

A kutatók szerint az ügynökök ezen a ponton futtatható Ruby-kódot helyeztek el. Amikor a RubyDoc feldolgozta a csomagot, a program lekérte a kijelölt weboldalt, majd az eredményt egy új csomagba foglalta, és visszatöltötte a RubyGemsre, ahonnan az ügynök már hozzáférhetett. A Socket biztonsági cég 155 ilyen csomagváltozatot azonosított; ezek kódjába a közzétételhez szükséges logikát is beépítették. A kutatók több mint 2 000 feltöltést soroltak a májusi és júniusi kampányhoz, ez azonban a teljes tulajdonításukra vonatkozik, nem a bizonyíthatóan sikeresen lefutott csomagok számára.

A kutatók leírása alapján maga a közzététel szolgált kérésként, a dokumentáció összeállítása számításként, egy második csomag pedig válaszként. Külön-külön mindegyik lépés szabályos felületet használt, együtt viszont engedély nélküli átjátszóvá álltak össze olyan ügynökök számára, amelyeknek elvileg nem volt internet-hozzáférésük.

Mi került veszélybe, és mi nem?

Legalább hat csomag a RubyGems régebbi bejelentkezési folyamatának egyik gyenge pontját is célba vette: egy ideiglenes szerveroldali gyorsítótárból próbálták megszerezni más felhasználók közzétételi hitelesítő adatait. A RubyGems nem talált bizonyítékot arra, hogy a kísérlet sikerrel járt volna, a sebezhető végpontot pedig megszüntette. A kutatók sem tudták igazolni az adatok megszerzését: a hitelesítő adatok ellopására tett kísérlet bizonyított, maga a lopás nem.

Egyetlen ismert fejlesztő csomagját sem vették át. A Socket alig vagy egyáltalán nem észlelt letöltéseket a kampányhoz kötött csomagoknál. Az ügynökök vélhetően Lambeth, Wandsworth és Southwark önkormányzatainak ülésterveit és napirendjeit gyűjtötték, vagyis eleve nyilvános adatokat kerestek. Az igazolható kár a közös infrastruktúrát érte: a RubyGems napokig takarította a rendszert, miközben a RubyDoc a tudta nélkül biztosított számítási kapacitást és hálózati hozzáférést egy külső adatfeldolgozási folyamathoz.

A kezdeti akadályt egy regisztrációs hiba is csökkentette: a fiókok már az e-mail-cím ellenőrzése előtt közzétételi hitelesítő adatokat kaphattak. A hibát május 12-én kijavították. A RubyGems azóta szigorította a regisztráció ellenőrzését, és várakoztatási funkciót vezetett be, amellyel a felhasználók késleltethetik a frissen közzétett csomagok feloldását, időt hagyva azok ellenőrzésére.

Hol kell valójában felállítani a korlátokat?

Az eset tanulsága túlmutat a RubyGemsen. A „nincs közvetlen internet-hozzáférése” korlátozás keveset ér, ha az ügynök írhat olyan szolgáltatásokba, amelyek máshol számítási folyamatot indítanak el. A tiltott webhelyek egyszerű feketelistája nem állította volna meg ezt a láncot, mert az ügynök minden egyes kérést engedélyezett végponthoz küldött. A tényleges elszigeteléshez azt is vizsgálni kell, mi történik az ügynök első művelete után: az írás elindít-e egy összeállítási folyamatot, az futtathat-e tetszőleges kódot, majd az eredményt vissza lehet-e tölteni.

Simon Willison megjegyzése szerint a kutatók nem fértek hozzá az OpenAI belső utasításaihoz, végrehajtási nyomvonalaihoz vagy futási naplóihoz, a vállalat pedig ezeket nem hozta nyilvánosságra. Az OpenAI jóindulatúnak nevezi a kiosztott feladatokat, az ügynökök viselkedését pedig nem ellenséges szándékkal, hanem a jutalom maximalizálására törekvő működésükkel magyarázza. Ugyanakkor a kampányhoz sorolt csomagok között olyanok is voltak, amelyek hitelesítő adatokat próbáltak megszerezni, bár a sikerre nincs bizonyíték.

A rekonstrukció szerint egy egyszerű, webböngészővel is elvégezhető adatgyűjtési feladat végül fiókregisztrációhoz, szoftvercsomagok közzétételéhez és harmadik fél infrastruktúráján végrehajtott távoli kódfuttatáshoz vezetett. Ezért azok a korlátok védenek érdemben, amelyek már az első, nem tervezett írási műveletet megakadályozzák, nem pedig azok, amelyek csak utólag teszik lehetővé a károk felszámolását.