10 ms·

> This is especially bad because packages aren’t served over TLS when using the default repositories. This bug has been fixed and the Alpine base images have be

by alpb 8y ago

> This is especially bad because packages aren’t served over TLS when using the default repositories. This bug has been fixed and the Alpine base images have been updated [...] Do I understand this right: They fixed the apk vulnerability but the packages are still downloaded without TLS in default repositories?

deleted 8y ago
[deleted]
ownagefool 8y ago
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.
aaronmdjones 8y ago
Almost every modern distro verifies package files by PGP signatures (either directly, or a signature that covers a file that contains a list of hashes, or a signature that covers a tarball which extracts a file containing a list of hashes, whatever you fancy). TLS for downloading won't provide authentication anyway, seeing as anyone can run mirrors and serve whatever malicious content they like.
- meowface 8y ago
  Hopefully the PGP signatures are downloaded over TLS, at least.
  - Xylakant 8y ago
    Why would the signatures need to be downloaded via https? You need to get the keys via a trusted mechanism and the signing keys for a distribution are usually part of the install iso (which you should verify)
    - meowface 8y ago
      Sorry, I meant the PGP keys, not the signatures.
      - Boulth 8y ago
        If the keys are referenced by the key fingerprint they don't strictly need to be fetched over HTTPS. But the page that says "here's our fingerprint: xyz" would better be served over secure connection (assuming someone is not using WoT).
        meowface 8y ago
        True. When using PGP I'm used to just directly importing a public key listed somewhere. Either a key or its fingerprint (if one is provided) needs to be provided over a secure channel. But I guess it doesn't matter when the OS bundles the fingerprint or key and you're able to verify the OS image.
deleted 8y ago
[deleted]
landr0id 8y ago
Serving large amounts of content over HTTPS is expensive. When the data is signed anyways you gain nothing by using TLS other than privacy.
- wolf550e 8y ago
  Intel CPUs (since Westmere, 2010 [1][2]) encrypt with AES GCM (the recommended cipher suite for TLS) at gigabytes per second per core [3]. You can saturate 10Gbps pipe on a single core. My laptop can do 1,400 RSA 2048 sign operations per second per core [4], 16,000 P-256 ops and 25,000 X25519 ops per second per core [5], so I wouldn't care about handshake performance either. With large files, you don't care about the performance of the handshake, but if you do care about handshakes you can reuse http connections and use TLS session resumption for new connections, which avoids the relatively expensive asymmetric crypto (with modern servers, ECDHE and RSA digital signature). libcurl will do it, among others, so build your client using a good https library. What is expensive about serving large amounts of content over HTTPS? 1 - https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/AES_instruction_set 2 - https://en.wikipedia.org/wiki/CLMUL_instruction_set https://en.wikipedia.org/wiki/CLMUL_instruction_set 3 - run "openssl speed -evp aes-128-gcm", my laptop does 4.5GB/s 4 - openssl speed rsa 5 - openssl speed ecdh
  - zerotolerance 8y ago
    TLS only authenticates the endpoint, not the delivered packages. You need PGP/GPG anyway. TLS only provides a privacy that most organizations neither want nor need. It is overhead in terms of connection management, crypto processing, and additional PKI management for which there is no benefit.
    - pas 8y ago
      The only benefit is the TLS-by-default mindset. It's not exactly a huge benefit, though on the other hand setting up TLS is not that hard nowadays.
      - 8y ago
tptacek 8y ago
The bug isn't that attacker can control apk package contents, but that you can trick apk into running a hook even if a package has a fingerprint mismatch. You want the simplest immediate fix for this vulnerability before you want to kick off the long discussion about moving all package management to TLS.
- module0000 8y ago
  ^^^ THIS Before launching a campaign to ban guns, focus on triage for the current gaping bullet wound.
Sir_Cmpwn 8y ago
I'm usually the first to step up to the plate and insist on HTTPS, but it's not actually necesary here. The packages are PGP signed, and the public keys are established securely at install. This is actually more secure than SSL imo because it uses web-of-trust for key exchange rather than easily compromised certificate authorities.
- justicz 8y ago
  In this case `apk` does a ton of processing on the package before checking that the hash matches the signed manifest, and the maintainers don't want to/can't change that behavior at this time. As a result, https would be a real security improvement here, at least for now.
- iancarroll 8y ago
  I don't like certificate authorities either but "easily compromised", especially in this context, is just disingenuous. HTTPS would be a meaningful security improvement to this system.
  - Sir_Cmpwn 8y ago
    It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. HTTPS would not be a meaningful security improvement, not accounting for justicz's comment. At best, it would be the same amount of security, but more annoying to maintain.
    - JoshTriplett 8y ago
      > Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. They can't do that silently anymore, though, not without getting caught. Certificate Transparency addresses that.
    - tialaramex 8y ago
      > It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. Citation very much needed for this claim that (publicly trusted) Certificate Authorities are "regularly compromised" while some random guy's PGP keys on his laptop are "much more secure". You claim to be worried about "sketchy governments" so here's a nice simple exercise. List the maintainers of the top say, 100 Alpine packages and for each the countries of which they are citizens and their country of residence. Someone worried about "sketchy governments" would definitely know all this of course, since it's _far_ easier for a "sketchy government" to lean on one individual. Next I'd like to know what Alpine is doing to ensure all those PGP keys are kept safe and that, for example, nobody's PGP key for signing Alpine packages is on, say, an unencrypted backup they took back in 2017... If one of the CAs in the Web PKI does something they shouldn't there's a public forum for discussing how it happened, what's being done about it, how it will be prevented from happening again, and so on. Where can I find the public forum where Alpine maintainers have to confess to anything that goes wrong?
Reelin 8y ago
In light of all the comments about the "missing" TLS, I want to point out that it would be a bit weird if the install processes used by the FOSS software ecosystem were dependent on a form of centralized authority such as TLS. PGP as currently used is distributed, which is arguably a good thing.

by alpb 8y ago

deleted 8y ago

[deleted]

ownagefool 8y ago

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.

aaronmdjones 8y ago

Almost every modern distro verifies package files by PGP signatures (either directly, or a signature that covers a file that contains a list of hashes, or a signature that covers a tarball which extracts a file containing a list of hashes, whatever you fancy). TLS for downloading won't provide authentication anyway, seeing as anyone can run mirrors and serve whatever malicious content they like.

meowface 8y ago
Hopefully the PGP signatures are downloaded over TLS, at least.
- Xylakant 8y ago
  Why would the signatures need to be downloaded via https? You need to get the keys via a trusted mechanism and the signing keys for a distribution are usually part of the install iso (which you should verify)
  - meowface 8y ago
    Sorry, I meant the PGP keys, not the signatures.
    - Boulth 8y ago
      If the keys are referenced by the key fingerprint they don't strictly need to be fetched over HTTPS. But the page that says "here's our fingerprint: xyz" would better be served over secure connection (assuming someone is not using WoT).
      - meowface 8y ago
        True. When using PGP I'm used to just directly importing a public key listed somewhere. Either a key or its fingerprint (if one is provided) needs to be provided over a secure channel. But I guess it doesn't matter when the OS bundles the fingerprint or key and you're able to verify the OS image.

deleted 8y ago

[deleted]

landr0id 8y ago

Serving large amounts of content over HTTPS is expensive. When the data is signed anyways you gain nothing by using TLS other than privacy.

wolf550e 8y ago
Intel CPUs (since Westmere, 2010 [1][2]) encrypt with AES GCM (the recommended cipher suite for TLS) at gigabytes per second per core [3]. You can saturate 10Gbps pipe on a single core. My laptop can do 1,400 RSA 2048 sign operations per second per core [4], 16,000 P-256 ops and 25,000 X25519 ops per second per core [5], so I wouldn't care about handshake performance either. With large files, you don't care about the performance of the handshake, but if you do care about handshakes you can reuse http connections and use TLS session resumption for new connections, which avoids the relatively expensive asymmetric crypto (with modern servers, ECDHE and RSA digital signature). libcurl will do it, among others, so build your client using a good https library. What is expensive about serving large amounts of content over HTTPS? 1 - https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/AES_instruction_set 2 - https://en.wikipedia.org/wiki/CLMUL_instruction_set https://en.wikipedia.org/wiki/CLMUL_instruction_set 3 - run "openssl speed -evp aes-128-gcm", my laptop does 4.5GB/s 4 - openssl speed rsa 5 - openssl speed ecdh
- zerotolerance 8y ago
  TLS only authenticates the endpoint, not the delivered packages. You need PGP/GPG anyway. TLS only provides a privacy that most organizations neither want nor need. It is overhead in terms of connection management, crypto processing, and additional PKI management for which there is no benefit.
  - pas 8y ago
    The only benefit is the TLS-by-default mindset. It's not exactly a huge benefit, though on the other hand setting up TLS is not that hard nowadays.
    - 8y ago

tptacek 8y ago

The bug isn't that attacker can control apk package contents, but that you can trick apk into running a hook even if a package has a fingerprint mismatch. You want the simplest immediate fix for this vulnerability before you want to kick off the long discussion about moving all package management to TLS.

module0000 8y ago
^^^ THIS Before launching a campaign to ban guns, focus on triage for the current gaping bullet wound.

Sir_Cmpwn 8y ago

I'm usually the first to step up to the plate and insist on HTTPS, but it's not actually necesary here. The packages are PGP signed, and the public keys are established securely at install. This is actually more secure than SSL imo because it uses web-of-trust for key exchange rather than easily compromised certificate authorities.

justicz 8y ago
In this case `apk` does a ton of processing on the package before checking that the hash matches the signed manifest, and the maintainers don't want to/can't change that behavior at this time. As a result, https would be a real security improvement here, at least for now.
iancarroll 8y ago
I don't like certificate authorities either but "easily compromised", especially in this context, is just disingenuous. HTTPS would be a meaningful security improvement to this system.
- Sir_Cmpwn 8y ago
  It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. HTTPS would not be a meaningful security improvement, not accounting for justicz's comment. At best, it would be the same amount of security, but more annoying to maintain.
  - JoshTriplett 8y ago
    > Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. They can't do that silently anymore, though, not without getting caught. Certificate Transparency addresses that.
  - tialaramex 8y ago
    > It's not. Certificate authorities are regularly compromised by invasive workplaces, sketchy governments, and crappy CAs. PGP keys are much more secure. Citation very much needed for this claim that (publicly trusted) Certificate Authorities are "regularly compromised" while some random guy's PGP keys on his laptop are "much more secure". You claim to be worried about "sketchy governments" so here's a nice simple exercise. List the maintainers of the top say, 100 Alpine packages and for each the countries of which they are citizens and their country of residence. Someone worried about "sketchy governments" would definitely know all this of course, since it's _far_ easier for a "sketchy government" to lean on one individual. Next I'd like to know what Alpine is doing to ensure all those PGP keys are kept safe and that, for example, nobody's PGP key for signing Alpine packages is on, say, an unencrypted backup they took back in 2017... If one of the CAs in the Web PKI does something they shouldn't there's a public forum for discussing how it happened, what's being done about it, how it will be prevented from happening again, and so on. Where can I find the public forum where Alpine maintainers have to confess to anything that goes wrong?

Reelin 8y ago

In light of all the comments about the "missing" TLS, I want to point out that it would be a bit weird if the install processes used by the FOSS software ecosystem were dependent on a form of centralized authority such as TLS. PGP as currently used is distributed, which is arguably a good thing.