11 ms·

Remote Code Execution in Alpine Linux

286 points by justicz 8y ago

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.
ris 8y ago
People really have to stop thinking they can write package managers.
- interfixus 8y ago
  This is a bummer, clearly. Otherwise, apk is pure joy to work with, as is indeed all of Alpine.
btmiller 8y ago
I can only think about this and be fearful due to the staggering number of Docker tutorials that happily whisk away the details as a sales pitch for streamlining the development process. Similar to the Node ecosystem, there's bound to be lots of junk out there that will never be updated.
- bigdubs 8y ago
  Alpine isn't junk, but it is a layer in a lot of things that people use (ex. `golang:1-alpine`). Docker just makes it super opaque when you have to rotate images.
- swingline-747 8y ago
  Docker containers multiply faster than rabbits in a forkbomb. It behooves Docker to do vulnerability and malware scans of containers, because letting random people have semi-sandboxed write and execute permissions on random other people's systems is a dangerous combination. That will cover some cases, but end-to-end personal accountability of container publishers is a necessary evil as there is unlikely a reasonable technical way to ensure there aren't malicious scripts in a given docker container. Signature-based malware scanning operates only in a limited fraction of the past since it requires submittal and review of what has been seen by a particular user AND submitted to a malware scanner publisher for analysis. Scenario: Anonymous docker publisher installs a kiddie porn i2p or tor downloader service hidden in a container for Apache Kafka. Random corporate trainer accidentially picks said container, blogs a howto with it and suggests its use in in-person and web-based courseware. IANAL but Who's liable? The end-users using it? The trainer? Docker? Disclaimer: I love Docker, but it needs some chain-of-custody assurance and greater visibility of container contents.
  - zerotolerance 8y ago
    Docker ships with support for image signing, execution authorization (based on trusted signatures), and distribution endpoint authentication (TLS / PKI). Most image registries offer deep package inspection, OSS package manifests, and CVE visibility. If all that isn't enough, individual image layers can be accessed and inspected by hand (they're just tar files). If you're looking for "end-to-end chain of custody" you're going to need to specify the ends. Image signatures get you point-in-stack authorship assertions. I'm not sure what else anyone could ask for here.
justinsaccount 8y ago
> When apk is pulling packages, it extracts them into / before checking that the hash matches what the signed manifest says it should be. Pros: downloading and installing packages is faster. Cons: vulnerabilities like this. Reading the commit message in https://github.com/alpinelinux/apk-tools/commit/6484ed9849f03971eb48ee1fdc21a2f128247eb1 https://github.com/alpinelinux/apk-tools/commit/6484ed9849f0... I'm not convinced they fixed it.
- justicz 8y ago
  Just to preempt some replies to this I can already picture: if you find more bugs, please report them to the maintainers I mentioned in the post and not via an HN comment!
  - justinsaccount 8y ago
    Of course :-)
- tinus_hn 8y ago
  That has to be one of the more moronic ideas I’ve seen in a long time.
tedunangst 8y ago
Looks mostly avoidable if O_NOFOLLOW had been used? But the fix doesn't seem to add that, instead relying on other checks?
monksy 8y ago
Isn't that the distro that the jre docker containers use as the base? EDIT: Just looked into that.. it looks like just the java 8 containers.
- atmosx 8y ago
  Alpine is a popular choice for containers because it has very small footprint.
malikolivier 8y ago
The author launched a bug bounty program for open source projects: https://bountygraph.com/ https://bountygraph.com/. That's a wonderful endeavor and I would gladly try to "convince" people I know to pledge money in it. Monetary incentives are important for open source maintainers, as they cannot always afford the time to work on their projects.
- crispweed 8y ago
  I don't know exactly how that bug bounty program works, but it feels like there may be some fundamental issues with bug bounties in the context of open source projects. For example, what is there to prevent someone from introducing a bug into an open source project, first of all, and then subsequently claiming a bounty for identifying and/fixing it? (Maybe this can end up by forcing more careful pull request auditing for security critical projects, but that seems like a big ask..)
ollieparanoid 8y ago
@justicz: that's one clever hack, thanks for explaining in detail how it works! In case somebody is wondering about Alpine Linux based postmarketOS, this is what I wrote on /r/linux regarding this issue: postmarketOS is directly using Alpine's apk-tools package from their repositories, so a simple "apk upgrade" will install the latest apk version where this is fixed. Regarding the pmbootstrap tool we are using for development to set up Alpine Linux chroots, just update to the latest git version with git pull as usually, and it will make sure that the apk version is installed where this is fixed before you can use any of the chroots. Pulling from git may seem strange, but we do not have a stable release yet for pmbootstrap, so this is the normal way to update the code anyway. We're getting closer to a stable release of pmbootstrap though.
efiecho 8y ago
It seems like the attack is not completely quiet as an error is printed while installing a modified package, either from compromised mirror or by man-in-the-middle: ERROR: ${package_name}: BAD signature Remote code execution will happen, but at least you will get a warning that something suspicious is going on.
- owl57 8y ago
  That is even red and there's no obvious way for the attacker to disable that. But do people really look at the build log as long as the build is successful and the intended containerized program seems to work just fine?
  - rmetzler 8y ago
    Maybe it's possible to overwrite already printed lines with terminal sequences.

286 points by justicz 8y ago

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.

ris 8y ago

People really have to stop thinking they can write package managers.

interfixus 8y ago
This is a bummer, clearly. Otherwise, apk is pure joy to work with, as is indeed all of Alpine.

btmiller 8y ago

I can only think about this and be fearful due to the staggering number of Docker tutorials that happily whisk away the details as a sales pitch for streamlining the development process. Similar to the Node ecosystem, there's bound to be lots of junk out there that will never be updated.

bigdubs 8y ago
Alpine isn't junk, but it is a layer in a lot of things that people use (ex. `golang:1-alpine`). Docker just makes it super opaque when you have to rotate images.
swingline-747 8y ago
Docker containers multiply faster than rabbits in a forkbomb. It behooves Docker to do vulnerability and malware scans of containers, because letting random people have semi-sandboxed write and execute permissions on random other people's systems is a dangerous combination. That will cover some cases, but end-to-end personal accountability of container publishers is a necessary evil as there is unlikely a reasonable technical way to ensure there aren't malicious scripts in a given docker container. Signature-based malware scanning operates only in a limited fraction of the past since it requires submittal and review of what has been seen by a particular user AND submitted to a malware scanner publisher for analysis. Scenario: Anonymous docker publisher installs a kiddie porn i2p or tor downloader service hidden in a container for Apache Kafka. Random corporate trainer accidentially picks said container, blogs a howto with it and suggests its use in in-person and web-based courseware. IANAL but Who's liable? The end-users using it? The trainer? Docker? Disclaimer: I love Docker, but it needs some chain-of-custody assurance and greater visibility of container contents.
- zerotolerance 8y ago
  Docker ships with support for image signing, execution authorization (based on trusted signatures), and distribution endpoint authentication (TLS / PKI). Most image registries offer deep package inspection, OSS package manifests, and CVE visibility. If all that isn't enough, individual image layers can be accessed and inspected by hand (they're just tar files). If you're looking for "end-to-end chain of custody" you're going to need to specify the ends. Image signatures get you point-in-stack authorship assertions. I'm not sure what else anyone could ask for here.

justinsaccount 8y ago

> When apk is pulling packages, it extracts them into / before checking that the hash matches what the signed manifest says it should be. Pros: downloading and installing packages is faster. Cons: vulnerabilities like this. Reading the commit message in https://github.com/alpinelinux/apk-tools/commit/6484ed9849f03971eb48ee1fdc21a2f128247eb1 https://github.com/alpinelinux/apk-tools/commit/6484ed9849f0... I'm not convinced they fixed it.

justicz 8y ago
Just to preempt some replies to this I can already picture: if you find more bugs, please report them to the maintainers I mentioned in the post and not via an HN comment!
- justinsaccount 8y ago
  Of course :-)
tinus_hn 8y ago
That has to be one of the more moronic ideas I’ve seen in a long time.

tedunangst 8y ago

Looks mostly avoidable if O_NOFOLLOW had been used? But the fix doesn't seem to add that, instead relying on other checks?

monksy 8y ago

Isn't that the distro that the jre docker containers use as the base? EDIT: Just looked into that.. it looks like just the java 8 containers.

atmosx 8y ago
Alpine is a popular choice for containers because it has very small footprint.

malikolivier 8y ago

The author launched a bug bounty program for open source projects: https://bountygraph.com/ https://bountygraph.com/. That's a wonderful endeavor and I would gladly try to "convince" people I know to pledge money in it. Monetary incentives are important for open source maintainers, as they cannot always afford the time to work on their projects.

crispweed 8y ago
I don't know exactly how that bug bounty program works, but it feels like there may be some fundamental issues with bug bounties in the context of open source projects. For example, what is there to prevent someone from introducing a bug into an open source project, first of all, and then subsequently claiming a bounty for identifying and/fixing it? (Maybe this can end up by forcing more careful pull request auditing for security critical projects, but that seems like a big ask..)

ollieparanoid 8y ago

@justicz: that's one clever hack, thanks for explaining in detail how it works! In case somebody is wondering about Alpine Linux based postmarketOS, this is what I wrote on /r/linux regarding this issue: postmarketOS is directly using Alpine's apk-tools package from their repositories, so a simple "apk upgrade" will install the latest apk version where this is fixed. Regarding the pmbootstrap tool we are using for development to set up Alpine Linux chroots, just update to the latest git version with git pull as usually, and it will make sure that the apk version is installed where this is fixed before you can use any of the chroots. Pulling from git may seem strange, but we do not have a stable release yet for pmbootstrap, so this is the normal way to update the code anyway. We're getting closer to a stable release of pmbootstrap though.

efiecho 8y ago

It seems like the attack is not completely quiet as an error is printed while installing a modified package, either from compromised mirror or by man-in-the-middle: ERROR: ${package_name}: BAD signature Remote code execution will happen, but at least you will get a warning that something suspicious is going on.

owl57 8y ago
That is even red and there's no obvious way for the attacker to disable that. But do people really look at the build log as long as the build is successful and the intended containerized program seems to work just fine?
- rmetzler 8y ago
  Maybe it's possible to overwrite already printed lines with terminal sequences.