8 ms·

Meanwhile most of us curl stuff directly into our shells sometimes: https://brew.sh https://brew.sh

• DarkWiiPlayer 7y ago
  At least in those cases we know it's happening and we can have a look at the script if we want.
  • gregoriol 7y ago
    Yes! I second that feeling: knowing we are executing something and that thing being open source, it's up to us to check (plus running shell scripts is for power users). Here the user, average joe doesn't know what's happening, and can't check anything as it is hidden.
    • jtbayly 7y ago
      But so what? All it’s doing is installing the tool he needs. He knows theoretically that this could be spyware or worse, but hey, everybody else is using it. Seems like no big deal. Same with that curl script. What are the chances it’s bad? Small. So you run it and hope for the best.
  • tpxl 7y ago
    Daily reminder: You can detect whether the script is being piped to shell or not, so inspecting the script, then curl | shell might not get you the same script. curl > file, inspect file, ./file is (probably) safe.
    • joombaga 7y ago
      It'll get you the same script, it just may not execute the same, right? curl is the thing being redirected, and the http server doesn't know about curl's redirections.
      • comfydragon 7y ago
        No, the point of the findings in that blog post is that a malicious HTTP server could infer that you're piping curl to bash, and serve you a _different_ script. Hence why it's safer to curl the script to a file, inspect the file, then execute locally.
        • joombaga 7y ago
          I don't see how they could serve you a different script. How would they make the inference?
          • DarkWiiPlayer 7y ago
            Read the article. It's based on timing; if you send a "sleep 10" command and then a bunch of data, the client will either display the "sleep 10" and go on consuming the data, or, if it's being executed, will actually sleep for 10 seconds and the data will pile up until its OS stops accepting new data, so you as the server will see that the client has suspended the download and can deduce that it's being executed live on the target machine. You can then choose how to end the script; with harmless looking code or the actual payload you want to run on their system.
            • joombaga 7y ago
              What article?
              • DarkWiiPlayer 7y ago
                It was linked in another comments a few ndoes up this tree
                • joombaga 7y ago
                  Found it. It was a parent sibling. Thanks. I understand now.
    • Tyr42 7y ago
      To expand on this, it is possible to tell apart the redirection to file and pipe to shell. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
      • DarkWiiPlayer 7y ago
        Sounds interesting and excessively comples; You can just as easily do this: - Send X bytes of the script - Send the line `curl my.server.com/asdjkfh` - Stop sending data, wait for a request to `/asdjkfh` - If you receive said request, start sending malicious data - If you don't, wait 5 seconds and continue sending a "fake" script
• stuff4ben 7y ago
  Oh I hate that! For apps I want that do that, I first search if there's alternative installation methods available and use those, even if it's more work. Barring that, I will usually take a look at the script for anything it tries to download or any permissions its trying to set. But if I'm in a hurry...sometimes I just run it...
• saagarjha 7y ago
  …that’s just one of the security issues with Homebrew.