Hacker News Reader

Comment by jjgreen | Hacker News Reader

   Anyone that wants to inspect the shell script can amend that line 
   to first save and view the script.

They can, but they may well not get the same output since, as is well-known, curl | sh can be detected on the server.

View on HN

I’m well aware of that. I didn’t make it explicit (as I thought it logically followed) that one would execute the local copy after review. Even putting aside the security aspect, downloading something twice makes little sense, so I thought the fact you would execute the saved file (again, after review) was pretty obvious.

Can't one do `curl $url | sh -c 'cat > /tmp/file'`?

Mind explaining why? I just tried it, and it works fine.

When we say "|sh can be detected on the server", this is not it. What you wrote is no different from `curl -o /tmp/file`.

In other words, you are saying that an HTTP server can detect distinguish between when the client is doing `curl $url | sh`, and when the client is doing `curl $url | sh -c 'cat > /tmp/file'`.

I'd love to hear the mechanism that the server would use to do that, if you have the time!

I'm sorry I just saw this, but the idea is that sh will read as it executes so you can detect it passively. If you make it `sleep 1` you can detect on the server side that your call to send() hangs until sh proceeds, for the same duration as the sleep. You need to put enough content to make the TCP buffers fill up, but that can be done with all those function definitions that you tend to see in those scripts anyway.

Or the script could also signal through an active mechanism, a different innocuous-looking HTTP request that makes the server switch the content to a malicious payload if it happens at the same time.

also it is well-known that scripts you downloaded can be run locally

Reply on news.ycombinator.com