4

I use the Git Bash on a Windows 8.1 machine.

Do I need to be concerned by Shellshock?

3

It is simple to test for yourself.

CVE-2014-6271

CVE-2014-6271 is the original shellshock bug. To see if you are vulnerable, run this code at the bash command prompt:

env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

If the output is:

Bash Test

Then you are fine. If, on the other hand, you see:

Bash is vulnerable!
Bash Test

Then your bash is vulnerable.

CVE-2014-7169

There is a newer related vulnerability. To test for this one, run this code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

If you see the following output:

date
cat: echo: No such file or directory

Then you are fine.

All versions of bash up through 4.3, which is the current version, were vulnerable to shellshock. Since patches keep getting updated, updating your version is probably a good idea.

Who is vulnerable?

According to Qualys, remote exploitation of shellshock may be possible in the following situations:

  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string)
  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

To be vulnerable on Windows, however, one would have to be using a version of one of the above service that invokes bash.

| improve this answer | |
  • Cheers John, the second script just gives me a syntax error for the first =. – BanksySan Sep 27 '14 at 22:46
  • 5
    This answers the question "Is my bash buggy". It doesn't answer the question "am I vulnerable". You're vulnerable if you have a buggy bash which can be started automatically by a service which passes unvalidated environment variables, such as a webserver with a CGI handler which invokes bash. That's pretty unlikely on a Windows machine, but certainly not impossible. – rici Sep 28 '14 at 0:43
  • @rici Good point. I added a section on potential vulnerabilities. – John1024 Sep 28 '14 at 2:28
  • @BanksySan In that case, I would suggest updating. – John1024 Sep 28 '14 at 3:05
  • This answer really should focus more on the last part and explain why or why not the vulnerability is relevant to Windows. It's very unlikely that anything in Windows depends on Bash or even executes privileged commands through it. – slhck Sep 28 '14 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.