4 ms·

Not using TLS on repos is pretty standard in distro packaging, though in the days of Lets Encrypt it seems sensible to change that. There may be a comment to b

Not using TLS on repos is pretty standard in distro packaging, though in the days of Lets Encrypt it seems sensible to change that. There may be a comment to be made about using random distros. Alpine was a tiny distro that became super popular despite presenting several problems, docker layers making size sorta not important, and despite the recommended base image being debian. Probably too late for that point though, and the distros popularity does suggest some of these companies should indeed donate.

alpb 8y ago
I see. It feels like apk (or for that matter, other package managers that use plain http) are just time bombs waiting to be exploited again and again.
- nicolaslem 8y ago
  Mandatory mention of https://whydoesaptnotusehttps.com https://whydoesaptnotusehttps.com
  - detaro 8y ago
    and https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
  - angry_octet 8y ago
    And yet, it is full of bullshit like this: "HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates." The worst sort of neckbeard nonsense. Signatures are if benefit in bandwidth constrained distribution, and for store and forward. Microsoft uses them for package distribution too (x.509 code signing). But there is no doubt that TLS makes interfering much harder. With the move to encrypted SNI and http/2 this will hopefully become moot.
- snuxoll 8y ago
  When you have mirrors outside the control of the project HTTPS doesn't do anything to protect you from malicious actors (even then, project-controlled mirrors could be compromised just as well). It can provide privacy, which is still beneficial; but, again, only of limited benefit since there's never a guarantee the mirrors aren't compromised. GPG signatures on packages are the correct solution, apk just did it wrong.
  - nebulous1 8y ago
    https was a practical issue at one time but it isn't anymore. This RCE would be far less severe if all communication was over TLS as the attacker couldn't just sit on the wire between the client and the server. It would still exist with TLS of course, but you can't say that TLS "can [only] provide privacy". The correct solution would be to do both TLS and GPG signatures.
    - Xylakant 8y ago
      Https does nothing to protect you from a compromised or evil mirror. You cannot trust https at all in this context, you need to rely on signatures.
      - nebulous1 8y ago
        You have ignored what I wrote
        ummonk 8y ago
        It's astounding how many people in this thread seem to think that a compromised mirror or compromised certificate authority is somehow a comparable risk to plain old MITM.
        zaarn 8y ago
        It baffles me as well. A lot of comments either seem to imply that TLS and PGP cannot coexist in a package manager or that because HTTPS doesn't protect you from Mussad replacing your phone with a brick of Uranium so you die of Cancer, the security advantage does not exist... Somehow the term "defense in depth" (aka "layers of security") has lost it's meaning.
- aseipp 8y ago
  TLS has nothing to do with it, though, and TLS-or-not isn't relevant to the vulnerability. This exact same issue would be a problem with TLS enabled on Alpine repositories, because any mirror could have just served you a malicious package that passed the fingerprint check anyway, all with a fancy, validated Let's Encrypt certificate. TLS only provides privacy[1]/some measure of inline MITM/tamper protection in cases like this, it can't fix a broken signing mechanism. Now, TLS, as a mechanism for establishing tamper-proof connections can mitigate some attacks, but that isn't the same thing. For example, another post here links to a packagecloud.io blog about Apt-without-TLS being insufficient and being vulnerable to many MitM attacks. For example, an attacker without TLS can just strip the signed metadata info and hand it to you, or they can do a freeze attack, so you pick up old packages (that might have security vulnerabilities). But these problems fundamentally have to do with the design of apt's update mechanism, and not the lack of TLS on the repositories. TLS is the transport layer; apt is what has to enforce the security policy (and indeed, if your TLS-powered Apt mirror has gone rogue, it can still pull off many of the same attacks anyway, regardless of TLS.) It can only mitigate the issue, not actually prevent it. Systems like The Update Framework (https://theupdateframework.github.io/ https://theupdateframework.github.io/) outline a design for secure update/package management frameworks that not only don't need TLS, but also are designed to prevent many of the problems that plague Apt, as well (freezes, rollbacks, endless data, etc). All that said, TLS is great for a number of reasons and worth using and enabling where-ever you can, of course. (It's cheap these days, and PKI in general is impossible to ignore/live without, so you might as well jump on the bandwagon and be proactive!) [1] Arguable, since the server can just log everything anyway and look at what you download. Most public package repository systems simply are not designed with transport-layer privacy in mind...
  - nebulous1 8y ago
    Lack of TLS allows this vulnerability to be attacked without compromising any of the mirrors, which makes it a lot more practical to attack.
move-on-by 8y ago
I'm not sure where you get "despite the recommended base image being debian". From the best practices docker docs: > Whenever possible, use current official repositories as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in size (currently under 5 MB), while still being a full Linux distribution. [1] [1] https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#from https://docs.docker.com/develop/develop-images/dockerfile_be...
- ownagefool 8y ago
  That's today. Debian was the recommended base image previously, and Alpine grew in popularity despite of this. The issues were more around DNS resolution based on musl not having the same bugs as glic (I believe, this is from memory). At the end of the day, I suppose the community has spoken, and docker backed that up by hiring an Alpine developer, and I suppose the rest is history. Not that I intend to be having a go at Alpine, all distros go through this. I was just making the point it's a fairly small distro in contributor numbers, and it seems to have become fairly important to the eco system.

alpb 8y ago

I see. It feels like apk (or for that matter, other package managers that use plain http) are just time bombs waiting to be exploited again and again.

nicolaslem 8y ago
Mandatory mention of https://whydoesaptnotusehttps.com https://whydoesaptnotusehttps.com
- detaro 8y ago
  and https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
- angry_octet 8y ago
  And yet, it is full of bullshit like this: "HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates." The worst sort of neckbeard nonsense. Signatures are if benefit in bandwidth constrained distribution, and for store and forward. Microsoft uses them for package distribution too (x.509 code signing). But there is no doubt that TLS makes interfering much harder. With the move to encrypted SNI and http/2 this will hopefully become moot.
snuxoll 8y ago
When you have mirrors outside the control of the project HTTPS doesn't do anything to protect you from malicious actors (even then, project-controlled mirrors could be compromised just as well). It can provide privacy, which is still beneficial; but, again, only of limited benefit since there's never a guarantee the mirrors aren't compromised. GPG signatures on packages are the correct solution, apk just did it wrong.
- nebulous1 8y ago
  https was a practical issue at one time but it isn't anymore. This RCE would be far less severe if all communication was over TLS as the attacker couldn't just sit on the wire between the client and the server. It would still exist with TLS of course, but you can't say that TLS "can [only] provide privacy". The correct solution would be to do both TLS and GPG signatures.
  - Xylakant 8y ago
    Https does nothing to protect you from a compromised or evil mirror. You cannot trust https at all in this context, you need to rely on signatures.
    - nebulous1 8y ago
      You have ignored what I wrote
      - ummonk 8y ago
        It's astounding how many people in this thread seem to think that a compromised mirror or compromised certificate authority is somehow a comparable risk to plain old MITM.
        zaarn 8y ago
        It baffles me as well. A lot of comments either seem to imply that TLS and PGP cannot coexist in a package manager or that because HTTPS doesn't protect you from Mussad replacing your phone with a brick of Uranium so you die of Cancer, the security advantage does not exist... Somehow the term "defense in depth" (aka "layers of security") has lost it's meaning.
aseipp 8y ago
TLS has nothing to do with it, though, and TLS-or-not isn't relevant to the vulnerability. This exact same issue would be a problem with TLS enabled on Alpine repositories, because any mirror could have just served you a malicious package that passed the fingerprint check anyway, all with a fancy, validated Let's Encrypt certificate. TLS only provides privacy[1]/some measure of inline MITM/tamper protection in cases like this, it can't fix a broken signing mechanism. Now, TLS, as a mechanism for establishing tamper-proof connections can mitigate some attacks, but that isn't the same thing. For example, another post here links to a packagecloud.io blog about Apt-without-TLS being insufficient and being vulnerable to many MitM attacks. For example, an attacker without TLS can just strip the signed metadata info and hand it to you, or they can do a freeze attack, so you pick up old packages (that might have security vulnerabilities). But these problems fundamentally have to do with the design of apt's update mechanism, and not the lack of TLS on the repositories. TLS is the transport layer; apt is what has to enforce the security policy (and indeed, if your TLS-powered Apt mirror has gone rogue, it can still pull off many of the same attacks anyway, regardless of TLS.) It can only mitigate the issue, not actually prevent it. Systems like The Update Framework (https://theupdateframework.github.io/ https://theupdateframework.github.io/) outline a design for secure update/package management frameworks that not only don't need TLS, but also are designed to prevent many of the problems that plague Apt, as well (freezes, rollbacks, endless data, etc). All that said, TLS is great for a number of reasons and worth using and enabling where-ever you can, of course. (It's cheap these days, and PKI in general is impossible to ignore/live without, so you might as well jump on the bandwagon and be proactive!) [1] Arguable, since the server can just log everything anyway and look at what you download. Most public package repository systems simply are not designed with transport-layer privacy in mind...
- nebulous1 8y ago
  Lack of TLS allows this vulnerability to be attacked without compromising any of the mirrors, which makes it a lot more practical to attack.

move-on-by 8y ago

I'm not sure where you get "despite the recommended base image being debian". From the best practices docker docs: > Whenever possible, use current official repositories as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in size (currently under 5 MB), while still being a full Linux distribution. [1] [1] https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#from https://docs.docker.com/develop/develop-images/dockerfile_be...

ownagefool 8y ago
That's today. Debian was the recommended base image previously, and Alpine grew in popularity despite of this. The issues were more around DNS resolution based on musl not having the same bugs as glic (I believe, this is from memory). At the end of the day, I suppose the community has spoken, and docker backed that up by hiring an Alpine developer, and I suppose the rest is history. Not that I intend to be having a go at Alpine, all distros go through this. I was just making the point it's a fairly small distro in contributor numbers, and it seems to have become fairly important to the eco system.