0

Is my understanding correct that in order to exploit via "Shell Shock", binary we influence needs to execute bash (and we need to have influence on command line)?

Therefore, am I correct, that if binary does not execute bash directly, and does not use system() system call (which uses shell for command evaluation), but, instead, calls helper programs via system calls from exec() family (or loads via dynamic loading like ld etc), than given binary is "shell shock" safe? (Of course it applies transitively, if we can influence how helper apps are calling their helper apps)

And if system exposes only such binaries to inputs from external world, that given system is "shell shock" safe ? (Therefore, checking for lack of system() calls and exec() calls of bash is good audit evaluation criteria?)

Improve this question

2 Answers 2

Reset to default
5

Wrong on both counts.

In order to exploit the "shellshock" vulnerability, an attacker needs to control at least one environment variable (easy to do through CGI, SSH, or DHCP), and bash needs to be invoked at some point with the modified environment: directly as the result of an exec(), indirectly through system() or equivalent, highly indirectly through exec() of a helper app that in turn calls system(), and so on.

bash doesn't need to be invoked by name, either. On many systems, /bin/sh is a symbolic or hard link to /bin/bash, so running any script that starts with #!/bin/sh will result in bash being run.

Improve this answer
1
  • Thanks for enlightening! I've missed this one additional option of overwriting environmental variable, leading later to exploitation of any bash inheriting this variable.
    – Grzegorz Wierzowiecki
    Sep 26, 2014 at 23:28
1

To add to what Mark said, it's also worth noting that execlp, execvp, and execvpe all invoke /bin/sh, as that's how they perform their path lookups. So, even without the 2nd-generational effects Mark mentions, just using the exec* family of functions does not guarantee bash will not be invoked. The correct fix is to make sure you have installed a patched version of bash that is not susceptible to shell shock. (Yes, that does not offer any protection against future vulnerabilities.)

Improve this answer
2
  • Do you have a reference for exec*p invoking /bin/sh? That's not my understanding and I just did a mini test program and it was not vulnerable, unlike system() which is vulnerable
    – paj28
    Sep 27, 2014 at 11:52
  • I thought they unconditionally executed /bin/sh, but it turns out that's only sometimes: "If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)"
    – David
    Sep 27, 2014 at 16:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .