Debian 9.7 Released To Address APT Security Issue

[dungeon]

Okay, I had 1.8~beta1.

So you are running sid, but okay. CVE-2019-3462 was mentioned even two times there, so no idea how you missed that

[cybertraveler]

Edit:
Never mind. I found the original source of the bug. I understand how it works now. Wow... that's nasty. I wonder how long this has been used to hack machines running updates over proxies (eg. things like Tor).
https://justi.cz/security/2019/01/22/apt-rce.html

This is mind blowing.

apt will execute this guy's malicious .deb without first checking it is properly signed.

I think the "http vs https" debate in this case is secondary to the more obvious problem. That being: after the data has been returned by the http module of apt, that data should not be processed (whether's it's a deb or a package list) until apt has confirmed that it has valid gpg signatures. You should obviously assume the http data is compromised and not trustworthy.

If this vulnerability was introduced deliberately or discovered by black hats, just imagine the damage that has been done using it.

Debian needs a massive audit. I have seriously lost faith in it after this.

I hope that some large companies using Debian or Ubuntu are right-now planning a proper audit.

Just think about it: imagine you were the person working on this apt code or writing on it. If it was me I would put a huge amount of focus on correct sig verification before my code processed any of this untrustworthy data. I'd be staring at my code for ages and writing a ton of tests for it to ensure this issue didn't happen. I'd have big and clear comments stating the security sensitive nature of this part of the code.

[Guest]

My understanding is that APT allows to download from HTTP, but that's all right cause they check the signature of the packages. This avoids the penalty associated with HTTPS.

HTTPS penalty? Are you f**king kidding me? Maybe decades ago, there was some huge penalty, now my smart watch can do HTTPS requests. There's no sane reason to continue sticking to HTTP, other than FUD.

[Guest]

TLS is problematic when using a proxy to cache package downloads.

The only people who do set up proxies for caching package downloads are either advanced users or organizations with IT departments - in either case, you can set up a local APT repo, which can then pull from remote APT repos, and HTTPS is no longer a problem in that case.

[JanW]

HTTPS penalty? Are you f**king kidding me? Maybe decades ago, there was some huge penalty, now my smart watch can do HTTPS requests. There's no sane reason to continue sticking to HTTP, other than FUD.

A caching proxy? I work at a university. For the campus uplink it might make a difference whether every Ubuntu machine on the site downloads the same package from the Ubuntu mirrors or from the on-site transparent proxy. Oh and it might make a difference for the mirrors. And it would definitely reduce the speed at which each client gets the packages.

Please correct me if I'm wrong, but I think this would be hard or impossible to achieve if all those machines used https?

[cybertraveler]

Please correct me if I'm wrong, but I think this would be hard or impossible to achieve if all those machines used https?

It's effectively impossible if the admin doesn't have access to the client machines.

If that admin does have access to the client machines, then they can install fake certificates on all the client machines and use special https proxying software on the network to intercept the traffic, decrypt it satisfy proxied requests and then re-encrypt it using the real certificates.

[bemerk]

If bandwith is a problem you can create a local mirror for the packages