相关疑难解决方法(0)

阅读CVE-2009-4487 的细节（这是关于日志文件中转义序列的危险）我有点惊讶。

引用CVE-2009-4487：

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

显然，这实际上并不是 nginx 中的安全漏洞，而是终端模拟器中的安全漏洞。

当然，也许cat将日志文件写入终端只是偶然发生的，但是将日志文件写入grep是很常见的。less也许清理转义序列，但谁知道什么 shell 命令不会改变转义序列......

我倾向于同意Varnish 的回应：

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

因此我的问题：

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

X 的哪些终端模拟器可以抵御这种攻击？

我有时会从curl 或本地文件系统中获取二进制文件。在大多数情况下，损坏的终端可以通过重置来修复。在其他情况下，特别是如果二进制文件很大，终端将卡住几分钟打印输出，如下所示：

又名

c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;
2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;
2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;
2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;

关于这个场景我有三个问题；

1. 2c1 是什么意思？为什么终端会打印这个？
2. 您是否见过cat在交互式会话中实际防范这种不良行为的情况？
3. 您对如何对这样的猫进行编程有什么建议（在 cee 或 golang 中）

我最初的本能是将 cat 包装在一个函数中来检测这一点，但我很快意识到这是相当困难的，而且会有很多边缘情况。

function cat() {
    # warn user if
    #   - argument 1 is a large  executable 
    #   - argument 1 to the previous command in the a pipe-chain looks like a large binary
    # abort if
    #   - session is interactive and we are able to detect 2c1 garbage
}

一个实用的解决方案可能是在查看“不安全”输入时始终使用 less （使用 LESSPIPE），但这个问题与寻呼机无关。我知道管子越来越少了。我每天都积极使用它们。也许 less+lesspipe是这个问题的解决方案，less 的作者在大约 20-30 …