连 cat readme.txt 都不安全？iTerm2 的 SSH 集成被劫持了

今天 HN 上最让人心里发毛的一条，是 Calif.io 的这篇长文：在 iTerm2 里，连 cat readme.txt 都可能触发代码执行。听起来很离谱，但背后的原理其实很清晰：iTerm2 的 SSH 集成功能，可以通过终端输出被恶意文件劫持。

iTerm2 有一个 SSH 集成功能，目的是让本地终端和远程 shell 之间有 richer 的交互。为了实现这个功能，iTerm2 会在远程 shell 里启动一个 conductor 脚本，然后通过终端 escape sequence 和这个 conductor 通信。通信协议包括 DCS 2000p 和 OSC 135 等 escape sequence。

问题在于：iTerm2 没有严格验证这些 escape sequence 是否真的来自可信的 conductor。也就是说，任何能往终端里输出恶意 escape sequence 的东西，都可以伪造 conductor 的身份，让 iTerm2 以为自己在和一个真实的 conductor 通信。

于是攻击者可以构造一个文件，里面包含伪造的 DCS 2000p hook 和伪造的 OSC 135 回复。当你在 iTerm2 里用 cat 打开这个文件时，iTerm2 会渲染这些 escape sequence，然后开始执行它内部的 conductor 工作流。这个工作流包括发送 getshell()、pythonversion() 等命令，最后会发送一个 run(...) 命令。

而 run(...) 命令的内容，是 base64 编码的。攻击者可以精心构造这个 base64 编码，让它的最后一个 128 字节 chunk 成为一个有效的相对路径，比如 ace/c+aliFIo。如果这个路径在本地存在并且可执行，那么当 iTerm2 把这个 chunk 写到 PTY 时，本地 shell 就会把它当作命令执行。

嗯，整个过程最可怕的地方，是它利用了 iTerm2 自己的功能。iTerm2 的 SSH 集成本身是一个合法功能，目的是提升用户体验。但因为它没有严格验证 conductor 的身份，这个功能就变成了一个攻击面。攻击者不需要任何远程服务，不需要任何网络访问，只需要一个能输出恶意 escape sequence 的文件，就能在本地触发代码执行。

这篇文章还提到一个细节：这个漏洞在 3 月 30 日报给 iTerm2，3 月 31 日就修复了。但修复版本还没有进入 stable release。也就是说，现在大多数用户仍然在使用有漏洞的版本。

从安全角度看，这件事的启发很直接：

第一，终端不再是"安全边界"。以前我们觉得终端是相对安全的环境，因为它只是输入输出设备。但现在终端功能越来越复杂，支持越来越多的 escape sequence 和协议，这些功能本身就可能成为攻击面。

第二，"信任"需要明确边界。iTerm2 的 SSH 集成功能，本质上是让本地终端信任远程 conductor。但这个信任没有明确的边界：任何能输出终端内容的东西，都可以伪造 conductor。这种模糊的信任模型，很容易被利用。

第三，AI 在漏洞挖掘上的能力还在提升。Calif.io 这个系列文章，从 Vim/Emacs 到 Samsung TV 再到 iTerm2，每次都是让 AI 自己去探索、自己去发现、自己去验证。这说明 AI 已经可以独立完成从"理解功能"到"发现漏洞"到"构造 exploit"的完整流程。

从工程角度看，这篇文章最有价值的建议，其实是"别把终端当黑盒"。如果你在用任何有复杂功能的终端模拟器，你需要清楚它的功能边界在哪里，它的信任模型是什么，以及哪些功能可能被滥用。你不能假设"终端只是输入输出设备"，因为现代终端已经远不止这个。

所以今天真正值得记住的，不是"cat readme.txt 不安全了"，而是另一句更根本的话：当终端开始支持越来越丰富的功能时，它就不再是一个简单的输入输出设备，而是一个可能有攻击面的复杂系统。而这件事，目前几乎完全在用户视野之外。