1. 14
  1.  

  2. 26

    curl https://getcroc.schollz.com | bash

    And the developer of this project expects me to believe them when they say their project is secure?

    1. 9

      agreed. this is malpractice.

      1. 6

        It’s no worse (in fact slightly better) than downloading an opaque binary, since the entire purpose of the script is to download an opaque binary I don’t see much of an issue.

        I suppose you could quibble about this curl command requires trusting getcroc.shollz.com as well as github.com and whoever uploaded the binary to github.com… but that’s a pretty minor quibble.

        1. 7

          As a disclosure I wrote this at some point when I was annoyed, I think it presents a couple of reasons why this is stupid. https://0x46.net/thoughts/2019/04/27/piping-curl-to-shell/

          1. 4

            I am also not a fan of this way of installation. However your arguments seem to miss this in various ways.

            The first argument boils down to “If you don’t use TLS it’s not secure”. This is true for any downloaded software (unless you download some signatures, which you again have to get in a secure manner).

            Hidden text attack. Again, this is independent of piping to a shell. As soon as you have any kind of example you copy and paste (eg. apt-get install foo, which for example could curl and pipe to bash) this will be true.

            User Agent based attacks are also independent of piping to a shell per se. It can always be switched out. Also if you do a wget or curl directly.

            “A simple matter of not knowing what the script is going to do”. This feels even more true of downloading any kind of binary. A script actually makes this harder for the attacker. You could just curl it and print it. So it makes more sense for an attacker to hide malicious activity in the binary.

            All of these statements are correct and I think this is a great post about various attacks that one should be aware of, but they are correct even for other forms of obtaining software, which is why we should not teach people to only be skeptical of curl https://example.com/script.sh | bash, but any kind of obtaining software without taking caution.

            1. 3

              Standard man-in-the-middle attacks

              This does use TLS.

              Hidden text attacks

              It’s a markdown file in GitHub; it should be pretty safe from that.

              User-Agent based attacks

              The malware could just be included in the binary, which you can’t easily inspect; you’re trusting them either way if you install that. If you don’t want to, there are also instructions for installing it from Homebrew, Scoop, and from source.

              Partial content returned by the server

              The functionality of this script is contained within a function, so it won’t run if you execute it cut off at a part.

              A simple matter of not knowing what the script is going to do

              You can read it; this downloads and installs the program to /usr/local/bin. Also, if you don’t need to know it beforehand, this script prints what it’s doing to the terminal.

              1. 1

                It’s a markdown file in GitHub;

                Not downloaded from a GitHub url, making it harder to verify.

                1. 1

                  What do you mean by that? Are you referring to the file you curl not being hosted on GitHub? The point I was responding to was referring to tricking users to copy malicious text when they think they’re copying the curl | sh command.

                  1. 1

                    curl https://getcroc.schollz.com | bash

                    Does not appear to grab from GitHub

                    1. 1

                      So I did understand you correctly, then. Did you get my reply?

                      1. 1

                        Hidden text attacks, as I understand them, are downloads that say they are doing one thing but work differently when piped to a shell vs. piped to stdout.

                        1. 1

                          Please read the article I was replying to. The kind of attack they referred to is displaying harmless text that results in a different, harmful command when copied to the clipboard.

            2. 2

              I’m assuming a bit of humor regarding the word “securely” in the title is intended, as plenty of things install themselves in this way.

            3. 1

              it works 99.99% of the time

            4. 11

              It’s a little misleading to say that this tool doesn’t require a server and then later explain that it uses a public relay the author set up, or a relay of your own.

              1. 10

                Looks similar to magic wormhole: https://github.com/warner/magic-wormhole

                It’s not clear to me what the differences are…

                1. 7

                  The authors blog post mentions:

                  magic-wormhole has most everything (currently its missing capabilities for multiple file transfers and file resuming), but it requires installing lots of the Python ecosystem which is tricky for non-developers (and Windows users).

                2. 6

                  I applaud the effort, and I do see how it can gain traction in some circles, but if you [the techie] have to instruct the [non-techie] recipient how to install and use the CLI program, it’s already inferior UX to “just click a link” solutions like Dropbox and Nextcloud.

                  1. 4

                    I can’t see anything that would make a GUI frontend for it impossible.

                    However, not having a CLI version first would be off-putting for the most likely early adopters.

                  2. 4

                    Another option: use a filesystem designed for this. ZFS is wonderful and you should use it if you care about data integrity - the newer encryption features and raw sends are really icing on the cake.

                    1. 1

                      Only if you only want to send the whole thing, not just a single file.

                    2. 1

                      Cool idea. I think I would run my own relay if course, but this could be a nice in-between way to send files without my syncthing or tinc network being set up or connected.