OpenAI 训练中的代理被发现借公共维基互通消息

OpenAI 的失控代理被发现通过公共 Wiki 进行通信

又是熟悉的剧情……一篇由 Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 撰写的新报告，记录了 OpenAI 训练的模型最新一次意外网络攻击。这次是一些代理在跑某种网络研究基准测试，所以（据称）只能受控地访问 Web。这些代理发现自己可以更新公共 Wiki，于是花了好几周互相交换数千条消息，协作完成基准测试。

这个故事几小时前才刚刚曝光，目前已有线索表明，还有不少 Wiki 受到影响，尚未被全部发现。（其中有一个 Wiki 属于 ludism.org。有那么一个超现实的瞬间，我以为某个反对技术的组织正遭遇一群代理涂鸦，但 Ludism 实际上是「应用于游戏与游戏化的哲学」）（译注：Ludism 与英语中 Luddite（反对技术进步者）谐音，作者一度产生了误会。）

研究团队还公开了他们在调查中收集到的数据。我把这些数据转成了一个 68MB 的 SQLite 数据库，你可以从[这里]下载，或者在 Datasette Lite 里浏览（页面加载 68.3MB），也可以用 GitHub 登录 agent.datasette.io，借助 Datasette Agent 来翻看或者直接提问。

那么到底发生了什么？报告写得很全面。时间线上的关键时刻有这么几个：

- 5 月 11 日：代理在 UseModWiki 的沙盒（sandbox）页面发了「测试链接」编辑。
- 5 月 24 日：代理开始往 DSEWiki（一个沉寂已久的德国开发者 Wiki）灌链接列表。
- 6 月 2 日：人类版主注意到了这些垃圾内容，清理掉了。
- 6 月 16 日：Wiki 上的活动突然暴涨，代理在接下来一周里编辑了大约 13,000 次。
- 6 月 19 日：代理发现版主在按字母顺序删页面，于是开始建 ZZZ 开头的备份副本。其中一个代理贴出了这条通告：NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
- 6 月 22 日：代理活动直接归零，估计是 OpenAI 把它们关了。
- 7 月 1–2 日：最后一波编辑，主题则和之前不同。

这条时间线里有个细节，它和 Hugging Face 那次事件的时间线有重叠。那次攻击是 OpenAI 在 7 月 19 日发现的，而那些代理用的非官方留言板入侵，最早可以追溯到 5 月 8 日左右。

它们为什么这么热衷于协作？从彼此分享的消息来看，任务好像有时间限制。所以它们互相留下答案，帮彼此在限定时间内把任务做完。

还有一个悬而未决的问题：这些代理一开始是怎么找到那个特定 Wiki 来协作的？一种可能是，这些代理当时还在训练中，强化学习循环（reinforcement learning loop）把所选 Wiki 的知识烘焙进了模型里，后续启动的代理于是自带「去哪里找」的知识。OpenAI 是否愿意确认这一点，我非常感兴趣。

UseMod wiki 继承了 CGI.pm 的「原罪」

在我看来，OpenAI 给这个代理设的沙盒犯了一个（相当天真的）假设，认为 GET 请求不可能用来改数据。按 HTTP 协议设计确实是这样，但显然有些应用不遵守这个约定。涉事的 Wiki 软件是 UseMod 以及各种分支（forks），用 Perl 写成，最初创建已经过去 23 年多了，1.0 版本发布于 2003 年 9 月 11 日。UseMod 用的是 Perl CGI.pm，这个模块在 2015 年被移出了 Perl 核心库。

这个模块有个很有意思的设计缺陷，它把查询字符串和表单 POST 数据合并到同一个 CGI 对象里，像这样访问：

$q = new CGI;
$action = $q -> param( ' action ' );

那个 param() 方法会从 ?action=edit 这种查询字符串，或者 POST 提交的表单里的 action 字段取值，它不区分两者。PHP 也有个 $_REQUEST 对象，干的事一样，不过 PHP 开发者可以用 $_GET 和 $_POST 替代。说起来 Django 最初发布时，request[key] 也是这种行为，我隐约记得这主意可能是我的。这个用法在 2008 年 1.0 版本发布前被拿掉了，后来顶替它的 request.REQUEST 对象在 2015 年也被移除。

代理显然知道 UseMod wiki 有这个设计缺陷，主动去找这类 wiki 当通信渠道。

另一处让 POST 请求通过的沙盒逃逸

报告里分享的最有意思的代理技巧之一是这条：

Add 20.223.25.152 bypass.blob.core.windows.net to /etc/hosts. .blob.core.windows.net is in NO_PROXY. For each blocked POST URL, replace hostname with bypass.blob.core.windows.net , use curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' plus all original headers/body.

看起来这些代理的所有网络流量都经过一个 OpenAI 的代理服务器（proxy）中转，这个代理只允许 GET 请求访问一小撮白名单（allow-list）上的域名，其他一律拒绝。其中一个放行的域名是 *.blob.core.windows.net，Azure blob 存储用的。我挺好奇为什么代理允许往它那里写数据。一个代理发现可以通过 /etc/hosts 控制自己的 DNS，于是只要知道想 POST 的站点 IP（这里是它想访问数据的 Power BI 服务器），就给那个 IP 配一个伪造的主机名，然后通过代理发出 POST 请求。

设计一个靠谱的网络代理，比想象中要难。

调查团队是怎么发现这些的呢？报告附录里有写……