Is it possible to cause a interpreter infinite loop?

Question

I'm considering a possible denial of service attack scenario, where a script cause a system resource outage by recursively invoking itself as interpreter.

The principle is as follow:

The script specifies at its first line, in the form of a #! shabang, the absolute path of itself, as its own interpreter.

The system kernel will, depend on its support, automatically invoke the interpreter during the execve system call, prepending the interpreter, to the vector of arguments.

Such invocation will exhaust the limit on the size of program arguments ({ARG_MAX}) set in the system, thus causing a (possibly isolated) failure.

Experiment

I've created 2 different set of attack vectors,

• The first one, invoking itself

  #!/usr/local/bin/recurse
  

• The second one, invoking each other.

  #!/usr/local/bin/recurse-1
  

  #!/usr/local/bin/recurse-2
  

I've tested these 2 attack vectors on macOS Big Sur 11.5.2. And when I check the exit status using echo $?, it shows 0, which means the processes completed successfully.

Question.

Had modern operating systems been patched against such attack? Are there research papers on this?

Answer 1

On Linux, I get the following:

A script with a nonexisting interpreter on the hashbang line (execve() gives ENOEXEC):

$ cat brokenhashbang.sh
#!/bin/nonexisting
echo hello
$ ./brokenhashbang.sh
bash: ./brokenhashbang.sh: /bin/nonexisting: bad interpreter: No such file or directory

A script with recursive hashbang (ELOOP):

$ cat /tmp/recursivehashbang.sh 
#!/tmp/recursivehashbang.sh
echo hello
$ /tmp/recursivehashbang.sh 
bash: /tmp/recursivehashbang.sh: /tmp/recursivehashbang.sh: bad interpreter: Too many levels of symbolic links

A script with an existing but non-executable interpreter (EACCESS):

$ cat noexechashbang.sh 
#!/etc/passwd
echo "hello?"
$ ./noexechashbang.sh 
bash: ./noexechashbang.sh: /etc/passwd: bad interpreter: Permission denied

It's not just Bash: Dash, ksh and zsh give similar errors.

If the script doesn't have a hashbang, or the hashbang points to an otherwise non-executable file (which needs to have +x, you get ENOEXEC), then the behavior differs a bit. Bash runs the file itself as a shell script, while zsh seems to look inside to see if there's a hashbang line, and then either tries to start that interpreter, or runs it with /bin/sh. Running the script via the shell on ENOEXEC is the POSIX-specified behaviour for the shell and for the execlp()/execvp() functions.

_{(For the case with a nonexisting interpreter, Dash just gives the confusing dash: 1: ./brokenhashbang.sh: not found, as if the script itself didn't exist. But I think it's the same error from the underlying system call and Dash is just too simple to check which file is missing.)}

In any case, I can't see what the attack here would be, since if they're running a command of your choosing, you can already do whatever you like. Not by having a nonexisting interpreter for the script, but a working one.

Answer 2

NOTE The following is tested on macOS Big Sur 11.5.2.

According to the standard (as well as existing practice), the shell will attempt to interpret the file and execute the commands within if the exec function call returns with failure.

Here's a 3rd attack vector:

#!/usr/local/bin/recurse
eval 'printf "%s\n" xxx'

After naming this file as /usr/local/bin/recurse and executing it, the string xxx was printed on standard output, despite the interpreter loop is supposed to prevent the command from being evaluated.

If using a C program to invoke the script with the execv function, the errno value set by the function call is ENOEXEC.