0x00 前言

Busybox是一个开源的软件项目，提供了各类Unix工具的实现。它已经存在很长时间了，广泛应用于各类项目中，该软件的主要应用领域为嵌入式设备和Linux发行版。 最近，Busybox越来越受欢迎，因为它被应用于容器的基础层。官方的Busybox Docker镜像拥有超过1000万的pull量（也可以理解为下载量）。

Busybox工具被称为小程序，使用不同的编译flag，用户可以自定义小程序，只编译与其使用相关的小程序。在我的研究成果中，我尝试使用更广泛的applet，例如Busybox shell。Busybox shell本身就是一个applet。它是一个ash shell的实现。经过一段时间针对shell各种功能的研究，我发现它的autocompletion功能的一个漏洞。简而言之，我发现名称中带有转义字符串文件的目录使用autocompletion功能时，这个转义字符串将不会被shell清理。为了要更好的理解这个漏洞，首先我们要先了解下什么是转义字符串，以及为什么使用转义字符串会产生安全问题。

0x01 转义字符串漏洞的状态

转义字符串（或控制字符串）是一系列改变终端行为并允许以某种方式与其交互的字符。一些基础的转义字符串是经常被使用的，例如用于格式化或改变颜色的字符串。然而，现代终端已经取消了历史终端中常用的一些字符串，可能是为了避免滥用这些字符串而产生安全问题。

到21世纪初期，使用转义字符串的攻击方式被公开披露、逐渐修复。在我过去挖到的这种终端漏洞中通常都是由于滥用终端提供的功能造成的。其中一个不错的实例是屏幕转储转义字符串，命令终端将屏幕内容保存到指定的文件中，在一些有缺陷的实现中可以达到覆盖任意文件的目的。另一个是window标题报告，一个字符串指示终端将其window的标题打印到命令行中，这里也可能是存在安全问题的，因为另一个字符串允许将window的标题改变为任意字符串。在过去，攻击者利用这些功能和其他功能来实现对终端漏洞的利用。但是，不要认为，现代的终端就不存在这种安全问题。最近的一个例子是CVE-2015-8971，在Terminology 终端仿真器中允许输出标题报告（即将程序window的title输出到终端中）。

其他的漏洞也是由于仿真器实现过程中导致的。通过搜索引擎简单搜索一下，PuTTY，xterm，rxvt，Apple终端，gnome终端等等都产生过许多类似的安全问题。在一次邮件列表的讨论中，Solar Designer提出了针对该类漏洞的解决方案，并展示了他是如何轻松地在热门终端挖到内存破坏和崩溃漏洞的。在他的电子邮件中，举了一个关于CVE-2017-7467的例子，minicom中的一个缓冲区溢出漏洞，可以通过转义字符串触发。MichałZalewski在回复这封电子邮件时列举了一些用于挖掘这类漏洞fuzz终端模拟器的方法。我认为在不久的将来可以看到更多关于该问题的CVE漏洞。 

无论如何，我建议大家看一下关于终端安全问题的这篇文章：https://marc.info/?l=bugtraq&m=104612710031920&q=p3。 这篇文章中提到了前面说到的攻击方式，同时给出了一些有趣的例子，影响较大的就是流程的终端仿真器（如rxvt和xterm）中允许转义字符串，从而可以造成任意命令执行漏洞。对于向了解更多信息的小伙伴，可以阅读Dejan Lukan的这篇文章：https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/。 在本文中，我还是想强调一下，即使在终端模拟器中不存在任何已知漏洞，转义字符串在非期望的打印时仍然可能导致安全问题。 

合法的转义字符串可以清除终端输入，移动光标或写入隐藏文本。攻击者可以利用格式来欺骗不知情的用户或管理员，并显示虚假信息。 因此，在终端上运行的程序应该清理掉可能包含转义字符串的外部内容。 在类似的程序中，仅就这个问题就在报告了许多漏洞。 例如，Apache有一个编号为CVE-2003-0020的漏洞，由于在其错误日志中不过滤转义字符串，在CVE-2003-0083在访问日志中仍然存在相同的问题，以及最近mod_rewrite写入日志的漏洞CVE-2013-1862。 在之前的搜索结果中我们可以看到，nginx，wget，sshd等其他应用程序都曝出过类似的安全问题。可以说，这些只是在所有安全问题中的一小部分啦！ 另外一个例子可以在我以前发表的关于RubyGems漏洞的文章中找到，有兴趣的同学可以看一下：https://www.twistlock.com/2017/09/01/recent-vulnerabilities-rubygems-security-alert。

0x02 Busybox ash shell漏洞完全解析

Busybox有相应的过滤代码用来检查转义字符串并对其进行替换。为了完整的复现漏洞，我在带有转义字符串的目录中创建文件，并在目录中运行ls命令。 写了一个简短的C语言代码来创建这样的文件：

int main()
 
{
    open("e[2Je[1;1He[48;5;92;15mTwistlockLabse[0m", O_RDWR | O_CREAT, S_IRUSR | S_IRGRP | S_IROTH);
}

我使用转义字符串来清除终端并突出显示我的文本信息。这实际上是没啥危害的，但对于漏洞演示来说已经足够了。ls的输出是必须的， – 危险字符被替换为问号。然而，正如你现在可能猜到的那样，当使用shell的自动完成功能时，文件名不会被清理。换句话说，按Tab键后，文件名中带有危险字符的文件的目录上的标签将打印转义字符输出到屏幕中。  

无论何时使用共享文件系统，本地共享物理设置或远程共享目录，或以其他方式在线下载文件或存档时，都可能使Busybox用户遭受攻击。恶意用户可能会插入具有漏洞利用代码文件名的文件，并利用用户终端中的漏洞完成攻击。例如，在共享计算机上，用户可以简单地在他的主目录中创建一个恶意文件，当管理员自动完成这个目录时，用户的转义字符串payload将生效。虽然使用新版的终端仿真程序可以使用户免受已知漏洞的攻击，但攻击者可能利用仿真程序中的0day漏洞。应该提醒一点，我使用了Busybox的默认Docker配置，如果使用任何不同的flag编译可能会产生与这里所述不同的结果。

0x03 漏洞影响

当我确认了这个安全问题确实存在时，我联系了目前的Busybox维护者Denys Vlasenko。Denys立即发布了一个修复程序，修复了这个问题：https://git.busybox.net/busybox/commit/?id=c3797d40a1c57352192c6106cc0f435e7d9c11e8。 然而，尽管在我的一再要求下，修复版本暂时没有发布。目前，更新Busybox的唯一方法是编译Busybox官方仓库中的代码。我会在twitter随时跟进这个问题：https://twitter.com/TwistlockLabs。

0x04 最后在说两句

在另一篇文章中，我最近公布了CVE-2017-15873和CVE-2017-15874漏洞，这是我在fuzz一些Busybox小程序之后发现的。 第一个CVE是Busybox的bzip2解压缩算法崩溃问题，第二个CVE是LZMA解压缩算法存在整数溢出漏洞。大家可以在Busybox的官方公告中获取到详细信息：https://bugs.busybox.net/show_bug.cgi?id=10431，https://bugs.busybox.net/show_bug.cgi?id=10436