1. 12
  1.  

  2. 2

    Prime example of why you should never pipe curl output straight into bash.

    I’m really surprised this is not a top story here or HN .. millions of projects are potentially compromised or have at least their CI secrets / API keys stolen.

    1. 2

      This was my first response as well, but in a way it represents a larger problem of auto-updating/live dependencies.

      From what I’ve seen in the past, the standard “alternative” to piping curl to the shell is to download the file, “read” it, and then execute it. [1] [2] [3] That wouldn’t’ve helped here. Even if a thoughtful user had downloaded the file and run it in two separate steps, they’d still be vulnerable.

      The “actual” solution would be to download, verify the checksum against something, and then execute the script. That an issue as well: where do you get the checksum from? For the codecov script, they post the checksums in the GitHub repo which might be a safe place. But if you’re downloading the file from a remote source it’s technically possible that file has also been compromised.

      If you instead download the file once, “pinning” it to a version: what if you’ve downloaded the file during the period when it was malicious. Now you’ve pinned a malicious version.

      There’s no easy solution here, and while I agree that curl | bash is a bad idea for many reasons, that isn’t the root issue here. This is a reminder that everything should be considered malicious, but little more than that.

      1. 3

        Even if a thoughtful user had downloaded the file and run it in two separate steps, they’d still be vulnerable.

        This is only true if they had downloaded it from the compromise window of February-March. The smart thing to do is download it once and drop it in your repo; that makes it trivial to go back later and see whether any given build was compromised. If people had done this instead of following codecov’s advice, then only projects which added codecov during that window would have been compromised, rather than literally every project which used codecov during the window.

        No one is saying that “avoiding curl|bash means you’re completely safe”; it’s all about limiting the blast radius of an intrusion.

        1. 2

          The thing is that a lot of people focus on the “piping curl to bash”-part; which is what the top comment did as well (“you should never pipe curl output straight into bash”). There is little difference between piping directly to bash or saving it first, or between that bash script and some library you added from your language package tool.

          The problem in this specific case – which is actually not very common because most curl | bash things are one-time installers – is that you’re always directly loading the code from a remote source, possibly dozens of times per day.

          A good solution would be to limit the access of such things; all it needs to do is read a file and upload it; there’s no need for it to access anything else on the filesystem, or even access the environment beyond a few basics. All of this is possible already I think, but not very easy. Certainly not as easy as something like:

          run-limit --deny-all \
              --allow-fs coverage.profile --allow-http api.codecov.com \
              --allow-env PATH --allow-env CODECOV_KEY \
              'curl codecov.com/sh | bash'