apt apt-get 中的远程执行代码

原文：Remote Code Execution in apt/apt-get
作者：Max Justicz
译者：Nanako@知道创宇404实验室

TL,DR:
我在apt中发现了一个漏洞，它允许网络中间人（或恶意包镜像）以root身份在安装软件包的机器上执行任意代码。该漏洞已在apt最新版本中被修复。如果您担心在更新过程中被利用，可以通过禁用http重定向来保护自己。为此，请运行：

如果当前镜像包在默认情况下重定向（意味着出现该标志时无法更新apt），则需要选择其它镜像或直接下载程序包。该链接可以找到有关Debian升级的具体说明。Ubuntu的声明可以在这里找到。

作为证明，我录制了一段攻击如下Dockerfile的视频：

背景

在获取数据时，apt将各种不同的数据传输协议的工作进程分离。然后，父进程通过stdin/stdout与这些工作人员进行通信， 利用一个类似http的协议告诉他们要下载的内容并将它放到文件系统上。例如，在一台机器上运行 apt install cowsay并用http请求下载相应包的时候，apt将提供/usr/lib/apt/methods/http目录，并返回100 Capabilities消息：

然后，父进程发送其配置并请求资源，如下所示：

然后工作进程会像下方这样响应：

当http服务器根据重定向进行响应时，工作进程返回103 Redirect而非201 URI Done。父进程根据此响应来确定接下来应该请求的资源：

漏洞

不幸的是，进行http下载的进程会对HTTP Location头进行url解码，并直接附加到103 Redirect响应中：

（注意：不同版本的apt之间存在重要差异。上述代码来自Debian最近使用的1.4.y版本。一些Ubuntu版本使用的是1.6.y，它不仅仅是直接附加URI。然而在后续的http提取程序发出的600 URI Acquire请求中仍然存在注入漏洞。其他版本我并没有做检查。）

因此，如果http服务器发送Location: /new-uri%0AFoo%3A%20Bar，http提取进程将回复以下内容：

或者，如果http服务器发送：

那么http提取进程会回复：

注入恶意包

因为我在我的验证程序中注入201 URI Done响应，所以我不得不处理没有下载任何包的问题。我需要一种方法让恶意的.deb进入系统，以便在Filename参数中使用。

为了实现这点，我利用了apt update时release.gpg文件具有可塑性，并安装在可预测的位置这个特点。具体来说，Release.gpg包含的PGP签名，如下所示：

只要注入的内容不接触到签名内容，apt的签名验证程序就不会报错，所以我拦截了release.gpg请求，并用我的恶意deb进行了预处理：

然后，我在201 URI Done响应中设置Filename参数：

http / https争议

默认情况下，Debian和Ubuntu都使用开箱即用的http存储库（Debian允许您在安装过程中选择所需镜像，但实际上不支持https存储库 - 您必须先安装apt-transport-https）。

如果程序包清单已签名，为什么还要使用https？毕竟，由于包的大小有限，隐私获益是最小的。而且使用https会使缓存受限。

也有对此很感兴趣的人。某些网站专门解释为什么在apt上下文中使用https没有意义。

这些都是很好的观点，但是我这篇文章中的bug是存在的。无独有偶——这是JannHorn在2016年发现的另一个具有相同影响的bug。没错，即使使用的是https，恶意镜像依然可以利用这样的漏洞。但我觉得，与其攻击使用http或TLS证书的deb.debian.org，还不如直接攻击目标服务器上的应用服务。

（假设apt-transport-https本身没有灾难性的破坏。我并没有审计，但它看起来像是围绕libcurl的一个相对较薄的包装。）

支持http是个好事。我只是认为把https作为更安全的默认存储库是值得的，如果用户选择这样做的话，允许他们降低安全级别。如果服务器包默认使用的是https，我就无法利用本文顶部的dockerfile。

总结

感谢apt维护者及时修补此漏洞，并感谢Debian安全团队协助披露。这个漏洞已经注册编号：CVE-2019-3462。

---

 

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/799/