content injection in http method (CVE-2019-3462)

[Julian Andres Klode]

apt, starting with version 0.8.15, decodes target URLs of redirects, but does not check them for newlines, allowing MiTM attackers (or repository mirrors) to inject arbitrary headers into the result returned to the main process.

If the URL embeds hashes of the supposed file, it can thus be used to disable any validation of the downloaded file, as the fake hashes will be prepended in front of the right hashes.

[Julian Andres Klode (juliank)]

Attached preliminary patch for disco. Still working on test case, will issue full debdiffs for all releases later.

[Julian Andres Klode (juliank)]

Diff for cosmic for review. If this looks good (maybe we do need a better changelog entry?), and Debian likes theirs, I'll move forward with more diffs for bionic, xenial, and trusty.

[Seth Arnold (seth-arnold)]

The whitelist is currently:

" !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~"

Normally browsers do not send # or any following content to the server. It feels like it ought not be included.

Normally spaces should be url-encoded as %20. It feels like it ought not be included.

$() ` | {} all feel likely to be attempts to tickle shells in various ways and unlikely to be useful in "real" redirects. I think these ought not be included.

Thanks

[Julian Andres Klode (juliank)]

The list applies to decoded URLs, not encoded (as apt has to decode redirect targets due to technical reasons). It's possible curly braces could occur on redirects. It's highly likely & is involved.

The list as is is all printable characters, and goes way above filtering in other software.

We should get apt fixed to not decode and reencode on redirects, but it's a bit complicated.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.2.29ubuntu0.1

---------------
apt (1.2.29ubuntu0.1) xenial-security; urgency=medium

  * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
    (LP: #1812353)

 -- Julian Andres Klode <email address hidden> Fri, 18 Jan 2019 11:54:00 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.7.0ubuntu0.1

---------------
apt (1.7.0ubuntu0.1) cosmic-security; urgency=medium

  * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
    (LP: #1812353)

 -- Julian Andres Klode <email address hidden> Fri, 18 Jan 2019 11:38:56 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.0.1ubuntu2.19

---------------
apt (1.0.1ubuntu2.19) trusty-security; urgency=medium

  * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
    (LP: #1812353)

 -- Julian Andres Klode <email address hidden> Fri, 18 Jan 2019 16:35:08 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.6.6ubuntu0.1

---------------
apt (1.6.6ubuntu0.1) bionic-security; urgency=medium

  * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
    (LP: #1812353)

 -- Julian Andres Klode <email address hidden> Fri, 18 Jan 2019 11:39:50 +0100

[Erlenmayr (erlenmayr)]

There would be a much lower risk if HTTP (without TLS) were not still the default for repositories.

This can actually also be abused by a MitM, he can always make your APT think that there are no new updates (a simple 304 Not Modified works), and then exploit recent vulnerabilities of which you have not received the fix.

[Christoph Anton Mitterer (calestyo)]

Is there any more detailed evaluation of this hole?

It reads absolutely catastrophic, like that secure APT is basically broken since 2011,… and if anyone has found that issue before (which one must assume in the worst case) any code could have been rather easily introduced in any Debian based system, from end users to DDs.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.8.0~alpha3.1

---------------
apt (1.8.0~alpha3.1) unstable; urgency=emergency

  * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
    (LP: #1812353)

 -- Julian Andres Klode <email address hidden> Tue, 22 Jan 2019 19:52:38 +0100

[Julian Andres Klode (juliank)]

@calestyo well, it is as catastrophic as it reads. You might want to read Max's blog post for more information about how he discovered it: https://justi.cz/security/2019/01/22/apt-rce.html

[Christoph Anton Mitterer (calestyo)]

Hmm that's pretty bad then (which is not to be read as blaming you or anyone else here).

Are there going to be any… "consequences"?

I mean trying to find out whether systems have been compromised is probably impossible... an attacker could have used this long ago to basically do everything, from silently taking over end user systems to secretly injecting code in development repos.
Sure one can argue that this might have been noticed - but it also might have been not.

But is there a chance to e.g. get full audits of apt done by security experts?

I'd assume that aptitude was also fully affected by this, right?

[Christoph Anton Mitterer (calestyo)]

Or is there anything going to happen wrt to https/TLS?

I, personally, are not convinced of doing this...

In this specific case, and rogue mirror could have still exploited the hole, and I'd assume there is nothing done to check the trustworthiness of mirror operators (there's no real way to do so).

Also, the X.509 trust model is inherently broken. 150 root CAs alone in the mozilla bundle (many of them which cannot be trusted per se by any sane person) and even more sub CAs... all of which can issue literally any certificate.

Using TLS would IMO only help (a tiny bit) if Debian (respectively the derivates) would operate their own CA (and only accept that for services they offer, like mirrors, BTS, gitlab, etc.).

[Erlenmayr (erlenmayr)]

@Christoph:
You can put HTTPS URLs into your "sources.list", many mirrors support it. The package "apt-transport-https" is not required, that is outdated information. APT supports HTTPS out of the box for a while now, it is just not the default.
Packets will still be validated using the Debian release OpenPGP key, regardless of which method of transport you use.

> an attacker could have used this long ago to basically do everything
That is the case for any kind of security vulnerability. But the risk is much higher after the bug is published.

> But is there a chance to e.g. get full audits of apt done by security experts?
Bugs happen, audits don't find all bugs. APT has been around for a while and as a core infrastructure was reviewed by many people.