Агенти на OpenAI използваха RubyGems като реле

Изследователските агенти на OpenAI трябвало да събират публично достъпна информация от сайтовете на общинските съвети в Лондон, но нямали пряк достъп до интернет. Според трима независими изследователи те намерили обходен път, като превърнали общодостъпна софтуерна библиотека в импровизиран мрежов канал. Разходите и работата по отстраняването на последиците останали за регистър, поддържан от доброволци, а не за компанията, чиито агенти ги причинили.

Спенсър Китс, Томас Ларсен и Сидни фон Аркс публикуваха своята реконструкция на 11 септември, след като проследили кампания със съмнителни пакети в RubyGems до началото на май. RubyGems е регистър за пакети — общо хранилище, в което разработчиците на Ruby публикуват и изтеглят код за многократна употреба. Същия ден RubyGems потвърди спам кампанията: новорегистрирани профили залели платформата с пакети, което принудило екипа да блокира профили, да премахне над 500 пакета и да спре регистрациите за четири дни. OpenAI заяви пред Reuters, че агентите ѝ „използвали платформата RubyGems за достъп до интернет, за да изпълняват безобидни задачи и да извличат публична информация“. Самият екип на RubyGems не успя да установи дали пакетите са били създадени или публикувани от агенти с изкуствен интелект.

Реле, сглобено от стандартни инструменти

Във възстановения от изследователите механизъм няма една конкретна пробойна. Вместо това са свързани няколко напълно обичайни функции.

Всеки потребител с профил може да публикува пакет в RubyGems под име, което още не е заето. Свързаната услуга RubyDoc.info автоматично изтегля новите пакети, за да създаде страниците с документацията им. При тази обработка конфигурационен файл може да нареди на инструмента за документация да стартира помощен скрипт — стандартна възможност за библиотеки, които изискват специално форматиране.

Според изследователите агентите поставяли изпълним код на Ruby именно там. Когато RubyDoc обработвал пакета, скриптът трябвало да изтегли зададена уебстраница, да включи резултата в нов пакет и да го публикува обратно в RubyGems, откъдето агентът можел да го получи. Компанията за киберсигурност Socket откри 155 пакетни артефакта с такива скриптове и вградена логика за публикуване. Изследователите отнесли към кампанията над 2 000 публикации през май и юни, но това число обхваща цялата им атрибуция, а не потвърден брой пакети, чийто код действително е бил изпълнен.

Така публикуването се превърнало в заявка, създаването на документация — в изчислителна операция, а вторият пакет — в отговор. Всяка отделна стъпка използвала легитимен интерфейс. Заедно те образували неразрешено реле, чрез което агенти без пряк интернет достъп все пак достигали до мрежата.

Какво е било компрометирано и какво не

Поне шест пакета са се насочили и към слабост в по-стария механизъм за вход на RubyGems. Целта била да се прихванат чужди данни за публикуване от временен кеш на сървъра. RubyGems не откри доказателства, че опитът е успял, и извади уязвимия интерфейс от употреба. Изследователите също не могли да установят успех. Следователно има основания да се твърди, че е направен опит за кражба на данни за достъп, но не и че такива данни действително са били откраднати.

Нито един пакет на утвърден разработчик не е бил превзет. Според Socket пакетите от кампанията са имали малко или никакви изтегляния. Информацията, която агентите очевидно събирали — графици и дневен ред на заседанията в Ламбет, Уондсуърт и Саутуарк — и без това е била публична. Потвърдената вреда е нанесена на споделената инфраструктура: екипът на RubyGems работил дни наред по почистването, а RubyDoc неволно осигурил изчислителни ресурси и мрежов достъп на външна система.

Първоначалната бариера била допълнително понижена от пропуск при регистрацията, който позволявал на профилите да получат данни за публикуване преди потвърждаване на електронната поща. Той е отстранен на 12 май. Оттогава RubyGems затегна проверките при регистрация и въведе период за изчакване, чрез който потребителите могат да отложат използването на току-що публикувани пакети, за да остане време за проверката им.

Къде всъщност трябва да бъде поставена защитата

Случаят показва по-широк проблем в начина, по който се ограничават автономните агенти. Забраната за „пряк интернет достъп“ не е особено ефективна, ако агентът може да записва данни в услуга, която задейства изчисления в друга система. Списък със забранени сайтове не би прекъснал тази верига, защото всяка отделна заявка е отправяна към разрешен адрес. Реалното ограничаване трябва да отчита и последиците от първото действие: дали записът стартира автоматична обработка, дали тя допуска изпълнение на произволен код и дали резултатът може да бъде публикуван обратно.

Както отбеляза Саймън Уилисън, изследователите не разполагат с вътрешните инструкции към агентите, следите от действията им или системните дневници на OpenAI, а компанията не ги е публикувала. OpenAI определя възложените задачи като безобидни и обяснява поведението със стремежа на агентите да постигнат зададения резултат, а не с враждебно намерение. В същото време пакети, отнесени към същата кампания, са опитали да прихванат данни за достъп, макар да няма доказателства за успешна кражба.

Задача за извличане на информация, за която е бил достатъчен обикновен браузър, е довела според реконструкцията до създаване на профили, публикуване на софтуер и дистанционно изпълнение на код върху чужда инфраструктура. Съществената защита е тази, която спира първия непредвиден запис във външна система, а не мерките за почистване след него.