Important APT security update - please read the instructions to upgrade APT safely

· feed2toot · 5 · 112 · 48

@debian Ouch. I wondered why Debian wasn't using HTTPS. Any plans to do so now, in the light of this vulnerability?

@wizzwizz4 Debian already supports https. But TLS certificates depends on CAs, and most on them aren't trustworthy. Unless you use DANE/HPKP, don't expect https to *prevent* MITM attacks.


@devnull Fair point. However, loads of CAs are trusted by default for _everything else_, and it's better to pile on extra layers so an attacker will need to break _all_ of them.

@wizzwizz4 That's a huge problem. CAs shouldn't be trusted, because they don't give a crap about security. They're only for profit.

More software need to support DANE, more admins need to learn how to configure DANE and HPKP properly.


1. Let's Encrypt.
2. It helps to prevent attackers from easily utilising a vulnerability in one layer of mitigation.

Yeah, it's not perfect. But yes, it's better than nothing. HTTPS + DANE is better than HTTPS + CAs, but HTTPS + DANE + CAs is even better. And @debian doesn't have DANE yet, anyway!

@wizzwizz4 Lits encrypt won't prevent CAs from doing harm for profit.

No, HTTPS + DANE + CA doesn't isn't better than.HTTP + DANE. CAs add nothing and have the ability to forge rogue certificates, unless HPKP (1) is used. And DANE can make self-signed certificate trusted without third parties.

The real problem is that clients doesn't support DANE natively, Firefox user to support it via an addon. And most servers' admins don't use it

1. Some clients dont support HPKP.


@devnull Ok, CAs don't make a DANE system stronger, but they do make a system with clients that don't support DANE stronger.

However, we're not talking about a system that doesn't support DANE. We're talking about a case where @debian controls the protocols that both ends speak. The code can be made to do nearly anything!

@wizzwizz4 Debian already supports https for apt. So HTTPS support is not an issue. But it would be better if both apt and debian repos use DANE with self-signed certificate mode and/or HPKP. If I recall correctly, support already DANE. I can't test anymore since Firefox 57 broke the compatibility with DNSEC/TSLA Validator plugin.

(And GPG signing is better that HTTPS, especially if HTTPS were used to "protect" non-signed packages)


@devnull @debian It would be better still if GPG over HTTPS + DANE was the default.

@wizzwizz4 CAs don't certify that websites are trustworthy, or that admins are who they claim to be. CAs aren't a criteria to decide whether we should trust a server or not. Trust level should never depend on whether a server uses a self-signed certificate or a CA-signed ones.

All CAs do is to make all certificates they sign trusted by clients that trust the signing CA. That doesn't mean they add extra security to HTTPS.


@devnull CAs are simply a method for sites to authenticate themselves – and a weak method at that. You're right in saying that CAs offer no advantage when DANE is around.

@wizzwizz4 @devnull @debian

As the goal is to trust debian, is it possible for debian to supply the needed certificate rather than let's encrypt?

@RussSharek @devnull That's what self-signing the certificate is, basically. It doesn't promise that the certificate is actually Debian's certificate, because you…

Oh, I see what you're saying. Debian is the CA, and bundles its own signature with Debian? Ehh… not sure how much security nuts would appreciate that. I certainly wouldn't appreciate the software distributor having the technical means to transparently intercept all of my traffic. But it's certainly a possible solution.

@wizzwizz4 > It doesn't promise that the certificate is actually Debian's certificate

CAs don't, they deliver forged certs to malicious third parties, either for profit (see what micro$oft did with ie certificates in Tunisia (and NOT only in Tunisia) years ago, with the help from malicious CA, to help the government to spy on people), or by mistake (even Let's Encrypt has been abused)

HPKP does, a certificate can't be valid if it hasn't been signed by the pinned keys.


@wizzwizz4 And the only persons that can pin a key are either the admins of the server you're trusting, or someone who succeeded to compromise the server and gain root access (or at least some privileged user), in which case you're screwed whether the certificate is CA-signed or not.


@wizzwizz4 > I certainly wouldn't appreciate the software distributor having the technical means to transparently intercept all of my traffic.

Not all traffic… just apt using a Debian CA, so it won't have to trust another CA/third party (The less entities you need to trust, the better. Less likely to be screwed over) . They wouldn't need to be a CA if they wanted to intercept your traffic, as you run code written by Debian, and third party software build and packaged ba Debian…


@devnull @RussSharek

If they were a CA for all traffic, they could intercept all traffic without changing any other code.

But yeah, you're right; it only needs to be a CA for apt, and can be in a special "apt CAs folder"… but that's yet more complexity! And complexity is the enemy of security.

@wizzwizz4 So the risk you're reffering to, if Debian used it's own CA for APT, is basically non-existent. Plus, if Debian does something malicious, it will be noticed… as it Free software, and it's user base is mostly technical people.


@devnull @RussSharek You know that by "Debian" I really mean whoever can steal the… yeah, you're right. No additional risk.


It feels weird at first glance, but properly locked to only be applicable to apt it seems like a surprisingly workable solution.

Mind you, I'm sitting in the cheap seats making all kinds of half-witted assumptions. Please someone smarter than me find a better way.


@wizzwizz4 There's no perfect security. Of course, the more security there is the better.

But if the package servers and the signing keys (with their passphrases if there's one) get stolen, then I don't see any solution. We are all screwed.


@wizzwizz4 Debian even disabled SSLKEYLOGFILE variable on non-dev Firefox builds (current and ESR) "for security" while it's non really a security code. There's more easier and effective/permanent attacks, than
- using an HTTPS debug option
- which requires physical access, and launching firefox from the same shell as the one where SSLKEYLOGFILE
- is temporary

Debian won't be interested in spying on users. It's not google/micro$oft/facebook/****



Yeah, it comes down to a question of whether or not you trust Debian not to be evil.


@RussSharek Yeah, but if you don't, don't use Debian or any derivative, or any derivative of derivative… and so on. So you wouldn't by concerned about that all.

If you use Debian, then by definition you do trust Debian, unless you're drunk or high when you install anld use your OS(es) (or really stupid)



I was just thinking about the massive chain of trust that is the Debian lineage as a whole.


@devnull @wizzwizz4

I'm also thinking "In Debian we trust, but we still review the damn code." ought to be a mission statement.

@RussSharek Agreed

(Now, I want money to have a Debian logo and "In Debian we trust, but we still review the damn code." written on it 😂 )


@devnull my IT manager always says « Trust doesn't exclude control » @RussSharek @wizzwizz4

@RussSharek Indeed. Just like any other OS (or even other software like clients for proprietary communication protocols with their own CA stores, firewall bypassing mechanisms (see skype)…). So being a CA for it's own repos is far less risky than many commonly accepted practices (For example using "apps" for centralized and proprietary online services, where the service provide controls the client code as well. Or using google and gmail and try to block web trackers "for privacy")


@devnull @RussSharek HSTS / HPKP weren't thought through; they have other vulnerabilities of their own and I don't think either are as applicable as DANE here.

@wizzwizz4 Not the same goal. DANE have a mode to verify sefl-signed certificate which makes CA obsoletes. If Debian is it's own CA, DANE wouldn't be necessary but it's a plus, as DANE can be used with a CA as well.

HPKP is to say "The certificate is only if it has been signed the this/these key(s)".

Let's say Debian has a CA for apt, If your goal is to check if apt repos cert have been signed by debian's CA and not by a malicious CA, checking the signing key is a good option.


@devnull @RussSharek The principle of remembering the public signing key is a good one.

HPKP is a half-baked standard.

@debian Also, what're the hashes for the `apt` updates meant to be?

We can `sudo apt-get update` then `apt-cache showpkg apt*` then check the hashes and then update it if it matches.

@trini Thanks! Because of your boost I saw that before unattended-upgrades managed to auto-upgrade it.

@debian I am a bit confused about the implications of this vulnerability. Aren't the packages signed with GPG in the first place? Or for that matter, couldn't HTTP/FTP be man in the middled in the first place?

@dratini0 @debian The hashes of a packages are on a list (the `Release` file) and the list is gpg-signed.
However, apt has protocol-specific helper programs that download the package and calculate its hash, and then pass the file location and resulting hash to apt. The vulnerability lets you inject something into the communication between apt and the helper, which means you can fool apt into thinking the hash of the downloaded file is different than it really is.

@dratini0 @debian This is kind of an example of a "cross-protocol attack"; an attacker can essentially inject some of the "apt->helpers" protocol via the HTTP protocol ("because bad URL decoding"). APT is trusting what the helper program told it (not aware that the attacker injected something more).
(I think the "real" warning/takeaway here is to be Extra Paranoid if you speak protocol A *and* protocol B in the same thing, especially when one of those is "implicitly trusted")

Sign in to participate in the conversation

Fosstodon is a Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.