如何避免终端中的转义序列攻击？

阅读CVE-2009-4487的详细信息（这与日志文件中转义序列的危险有关）令我有些惊讶。

引用CVE-2009-4487：

nginx 0.7.64将数据写入日志文件，而无需清除不可打印的字符，这可能允许远程攻击者通过包含终端仿真器转义序列的HTTP请求来修改窗口的标题，或者可能执行任意命令或覆盖文件。

显然，这并不是nginx中的安全漏洞，而是终端仿真器中的安全漏洞。

当然，可能cat只是偶然地将日志文件发送到终端，但是grep很常见。less也许可以清理转义序列，但是谁知道什么shell命令不会更改转义序列...

我倾向于同意Varnish的回复：

通常会定期询问终端响应转义的智慧，但是仍然没有一个主要的终端仿真程序适合丢弃这些序列，这可能是在与不再使用的1970's技术兼容的错误尝试。[..]从安全性的角度来看，与其责怪编写日志文件的所有程序，不如让终端仿真程序停止做愚蠢的事情，从而一次解决此问题和其他安全性问题，将更有效率。并为所有人。

因此，我的问题是：

如何保护我的xterm，使其不再能够通过转义序列执行命令或覆盖文件？

X的哪些终端仿真器可以抵抗这种攻击？

VT100终端（所有现代终端仿真器都在某种程度上进行了仿真）支持许多有问题的命令，但是现代仿真器或发行版禁用了问题更多，使用较少的命令。这是潜在风险转义序列的不完整列表（不包括仅使显示无法以某种方式显示的序列）：

• HD Moore报告的 rxvt和Eterm中的任意日志文件命令。这些确实是主要的错误，所幸已长期修复。
• 由ENQ（Ctrl+E）调用的answerback命令，也称为“返回终端状态” 。这会将文本插入终端，就像用户键入文本一样。但是，此文本不受攻击者的控制：它是终端的自己的名称，通常类似于xterm或screen。在我的系统上（Debian压榨），xterm默认返回空字符串（由answerbackString资源控制）。
• 发送设备属性命令ESC [ c和朋友。终端以回应ESC [ … c（其中…只能包含数字和ASCII标点符号）。这是一种查询某些终端功能的方法，这些功能通常已过时，但可能已被旧应用程序使用。同样，终端的响应与用户输入是无法区分的，但是它不受攻击者的控制。控制序列可能看起来像功能键，但是仅当用户具有不寻常的配置时（我遇到的所有常规设置都没有有效的功能键转义序列，该序列是终端响应的前缀）。
• 各种设备控制功能（DCS转义，以开头ESC P）。
  • 我不知道通过DECUDK在典型的终端仿真器上（设置用户定义的键）会造成什么危害。
  • DECRQSS（请求状态字符串）是终端以转义序列响应的另一个命令，这次以\eP; 开头。这可能是有问题的，因为\eP它是有效的密钥（Alt+ Shift+ P）。
  • Xterm还有另外两个实验功能：ESC P + p …和ESC P + q …，用于获取和设置termcap字符串。根据描述，这至少可以用于修改功能键的效果。
• 几个状态报告命令：（ESC [ … n设备状态报告）。终端以转义序列响应。这些转义序列中的大多数都不对应于功能键转义序列。一个看起来很成问题：到的报告ESC [ 6 n格式为，其中和是数字序列，看起来有些修饰符。ESC [ x ; y RxyF3
• 窗口操作命令ESC [ … t。
  • 其中一些允许调整xterm窗口的大小，图标化等，这会造成破坏。
  • 其中一些导致终端以逃逸序列响应。这些转义序列中的大多数看上去都是低风险的，但是有两个危险的命令：分别针对ESC [ 2 0 t并ESC [ 2 1 t包括终端窗口的图标标签和标题的答案，攻击者可以选择这些命令。
  • 至少在Debian压榨下，xterm默认会忽略这些命令。可以通过设置allowWindowOps资源或有选择地通过disallowedWindowOps资源来启用它们。Ubuntu 10.04下的Gnome-terminal默认情况下甚至实现标题应答。我没有检查其他终端或版本。
• 用于设置终端标题或图标名称的命令。在xterm和大多数其他X终端下，它们是。在“屏幕”下，转义序列为。我发现这些命令被高估了。尽管它们确实允许一些恶作剧，但是任何网页都存在相同的问题。在窗口上仅根据其标题而不是根据其类别进行操作类似于打开一个文件，该文件的名称是由不信任方提供给您的，或者不引用shell脚本中的可变扩展名，或者在鼻子上拍打狂犬病—如果被咬，请不要抱怨。ESC ] digit ; title ESC \ESC k title ESC \

我发现Varnish的回应很轻率。感觉就像是在试图怪罪别人，还是在安全性纳粹模式下（任何安全问题，无论是真实的还是不安全的，都在为功能打黑）。

通常会定期询问终端响应转义的智慧，但是仍然没有一个主要的终端仿真程序适合丢弃这些序列，这可能是在与不再使用的1970's技术兼容的错误尝试。（…）
从安全性的角度来看，与其责怪编写日志文件的所有程序，不如让终端仿真程序停止做愚蠢的事情，从而一劳永逸地解决此问题和其他安全问题，这将更有效率。对所有人。

许多答案都是有用的功能：应用程序确实需要了解诸如光标位置和窗口大小之类的内容。设置窗口标题也非常有用。可能完全依赖ioctl于这些调用，但是这将需要其他代码和实用程序来进行这些ioctl调用，并将它们转换为传递给文件描述符的unix样式的文本。现在更改这些接口将是一项繁重的工作，但收效甚微。

文本文件不应包含非打印字符，例如控制字符。日志文件通常应为文本文件。日志文件不应包含控制字符。

如果您担心某个文件可能包含转义序列，请在编辑器中将其打开，或者使用less不带-ror -R选项的文件进行查看，或者通过进行查看cat -v。

这不是那么简单。很多人都有代码将xterm标题设置为提示等内容的一部分，并且出于非常充分的理由（因为shutdown从错误的终端窗口中使用错误的计算机的人可以告诉您！）。因此，正确地修复它涉及引入安全性上下文，从而使外壳与终端仿真器以及可能的人们的dotfile之间的交互严重复杂化。或者，您可以采用低廉的租金解决方案，对终端中可能显示的任何内容进行消毒；这在很大程度上减少了转义控制字符的可能性，无论如何都应该这样做以使它们脱颖而出（因为在日志文件中，它们可以指示有人试图注入shellcode）。

（顺便说一句，punycode是同类问题的更为严重的例子，尽管如此，punycode却已成为正式标准。有时，安全性归结为缓解了人们无法控制的不安全设计。）