91–100 of 166 posts
Earlier quoted context omitted.
He never explains why he wants to use HTTP, it’s only about why he thinks HTTPS isn’t nesscary.
Some country's firewalls distrupt https, which makes downloading things via https difficult.
I was expect a buffer overflow but this is a quoting issue which is equally applicable to all languages. Are the any language-level methods which make such bugs impossible (or much harder)? Heavy-weight strongly-typed HTTP libraries can force you to always construct headers in a way that handles quoting for you but people seem to love "light" solutions.
Strong typing isn't relevant here, this is applicable in any language. But the lib needs to know when you're putting text in a header name and when in the value.
Earlier quoted context omitted.
He never explains why he wants to use HTTP, it’s only about why he thinks HTTPS isn’t nesscary.
HTTP is the null hypothesis, since it's simpler. Usually there is a great reason to reject this null hypothesis - it prevents security vulnerabilities. But if there is no added value, then there is no reason to do it. Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?
You can see this pro-HTTPS opinion all over this discussion.
As for your "consider", I personally do double-wrap many streams: I have a VPN for my browser. The VPN is great for hiding my home traffic from being spied on by my ISP. Without the VPN, HTTPS streams would reveal hostnames (SNI) and IP addresses to my ISP.
Earlier quoted context omitted.
Yep, this is our daily reminder that they're called "testing" and "unstable" for a reason. They're not meant for production.
New fixes often land in unstable/testing before going to stable branches.
That's why the distribution is baked for months before being called stable.
Earlier quoted context omitted.
No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file befor…
Oh for god’s sake will you stop spreading nonsense FUD about https? https is not “broken”. The majority of websites run on https now; most system update mechanisms with the VERY notable exception of apt use https to serve updates. Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http, and you mitigate attacks like this pos…
We are talking about a specific use case of https: software repositories, which are far higher-value targets than your random website, with another set of challenges. Your package manager can actually do some things as root; once it's owned, your system is Game Over.
Adding yet another lib on top of the (?) most important piece of software on your computer is not a risk to take lightly. There are more elegant solutions (signatures, priv-sep, not trusting anything until authenticated, etc.) that require less risky code to run, and fewer people to come into play.
> Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http
Irrelevant. We're talking about instant game over if it goes to sh.. even if just once. More attack surface = more vulnerabilities.
I'm not familiar with established procedures in such cases, and am curious about the rationale for omitting a time window for the update.
Using HTTP for apt may seem bad, but you should really pay attention to Ubuntu itself: https://github.com/canonical-websites/www.ubuntu.com/issues/... Ubuntu ISOs aren't served securely and are trivially easy to MitM attack. This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...
Using HTTP for apt may seem bad, but you should really pay attention to Ubuntu itself: https://github.com/canonical-websites/www.ubuntu.com/issues/... Ubuntu ISOs aren't served securely and are trivially easy to MitM attack. This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...
Wow, that's pretty stunning and I'm honestly quite shocked it's still the case in '19. Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning. [edit] Looks like ISO signatures are served over HTTP as well.
The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.
Earlier quoted context omitted.
He never explains why he wants to use HTTP, it’s only about why he thinks HTTPS isn’t nesscary.
Some country's firewalls distrupt https, which makes downloading things via https difficult.
Am I crazy, or is the bigger problem here not the fact that Apt will just install whatever random package the server provides, whether your system trusts its GPG key or not? What the hell is the point of the keys if the packages are installed anyway??
Usually, the packages themselves are not signed with GPG, only the Release file is (containing the hashes of all .deb files). This is actually the default of both Debian and Ubuntu. I never quite understood the reasons behind it... I'd not expect this vuln to happen, though. More info: https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-v...
"The parent process will trust the hashes returned in the injected 201 URI Done 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."
Wtf? This sounds like Apt is just downloading a gpg file and checking if it matches a hash in an HTTP header, and if it does, it just uses whatever is specified, regardless of whether your system already had the right key imported? This makes no sense. Any mirror could return whatever headers it wanted.
This is the real vuln, not header injection. If Apt isn't verifying packages against the keys I had before I started running Apt, there was never any security to begin with. An attacker on a mirror could just provide their own gpg key and Releases file and install arbitrary evil packages.
Can somebody who knows C++ please verify that their fixes actually stop installing packages if the GPG key wasn't already imported into the system? https://github.com/Debian/apt/commit/690bc2923814b3620ace1ff...