6 ms·

Shell Shock Exploitation Vectors

142 points by dfranke 12y ago

calpaterson 12y ago
Somewhat ironic for all the noise made about qmail that many configurations of it are vulnerable. I wonder if Bernstein will be paying out that $1000 reward, and if so, to who See section 1.3: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
- dfranke 12y ago
  The qmail bounty explicitly disclaims "bugs outside of qmail", which this one clearly is. So, no.
  - kag 12y ago
    Why it's not exploitable without the shellshock-vulnerable bash, you could argue that qmail is not validating the input in accordance with the RFCs. In fact, that's one of the things I said here: http://marc.info/?l=qmail&m=141183309314366&w=2 http://marc.info/?l=qmail&m=141183309314366&w=2
    - panic 12y ago
      Input validation is an orthogonal issue here, since bash doesn't know anything about RFC821/RFC2821, doesn't expect data in that format, and doesn't make any guarantees about what it will or won't do on such data. The only reasonable policy for a shell to follow is to be entirely input-agnostic and never execute code based on the contents of an environment variable (regardless of which RFCs the contents conform to).
      - kag 12y ago
        Of course bash doesn't know and shouldn't know about the SMTP RFCs. Yes, bash shouldn't execute code in variables. I was talking about input validation in qmail itself, not bash. Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.
_delirium 12y ago
One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that invoke /bin/sh. If bash is not installed as /bin/sh, as is the case on Debian and Ubuntu, do any of these (inetd, exim, etc.) still explicitly call it? Put differently, is this mainly an issue for distributions that ship bash as /bin/sh? Or do users of distributions like Debian also need to worry about common system services setting bash shell variables? Maybe I'll try to answer that by pulling a bunch of Debian source packages and grepping for explicit calls to bash...
- lambda 12y ago
  The one major one I found was the DHCP vulnerability; if you use ifupdown and configure and interface via DHCP, that uses dhclient, which invokes dhclient-script with attacker controlled variables. dhclient-script is explicitly written in bash, so is vulnerable. I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
- pja 12y ago
  Even if they don't explicitly invoke bash, it's possible that they call a program which calls a program which invokes a bash script somewhere. Debian switched /bin/sh to link to dash a while back, but some maintainers decided to simply change the #!/bin/sh at the top of the shell scripts in their packages to #!/bin/bash rather than remove the bashisms. dhclient is the worst offender in the current kerfuffle, but I'm sure there are others.
  - tokenizerrr 12y ago
    They did switch /bin/sh to dash, which is why it seems to me that grepping for "bash" would be quite effective.
patio11 12y ago
On the theory that it is more likely to help HNers than the bad guys: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html http://httpd.apache.org/docs/2.2/mod/mod_ssl.html . Note in particular the part about StdEnvVars. The docs say it is off by default, but it is actually on in a lot of common deployment scenarios, for example if most of your apache configs were sourced from the big "apt-get install foo bar baz" line everyone copies from a blog post to get a working LAMP installation on an Ubuntu box. I have not POCed this yet, but if I were trying to, I'd first try to make a client certificate with a highly non-standard Distinguished Name. It doesn't particularly matter if it fails validation as long as it doesn't fail in such a way that Apache dies before passing your information deeper into the guts of the web app. After that point you're just looking for e.g. any page or library in the web app you can coerce to do a system() call or similar. While I was poking around in my own apps something like system(...) in Ruby on Ubuntu actually called /bin/sh rather than bash, but I think that is probably not the case for every combination of stack and distro.
- hawkice 12y ago
  Slightly more precisely: /bin/sh on ubuntu points to Dash, which is substantially more minimal than bash. Probably not chosen for security (I imagine speed was on their mind), but good either way.
  - stakent 12y ago
    In Debian /bin/sh points to dash too.
- bch 12y ago
  Re: /bin/sh versus /bin/bash (or similar) - note that many Linux systems link /bin/sh -> /bin/bash, so seeing /bin/sh, or knowing that's what system() calls, is not sufficient information on its own to determine your risk.
  - patio11 12y ago
    Yep. More broadly, I think the most sensible strategy for determining whether a system is at risk is "If it has bash and isn't airgapped assume that it's vulnerable because it is highly likely someone will find the vector you overlook."
idorosen 12y ago
For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and the CVE-2014-7169 patch. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched https://github.com/ido/macosx-bash-92-shellshock-patched Binary releases are here: https://github.com/ido/macosx-bash-92-shellshock-patched/releases https://github.com/ido/macosx-bash-92-shellshock-patched/rel... ...including a .pkg file that can be installed with a double-click. Instruction here: https://github.com/ido/macosx-bash-92-shellshock-patched/blob/master/README.md https://github.com/ido/macosx-bash-92-shellshock-patched/blo...
- JackC 12y ago
  This appears (to me) to be another good temporary fix for OS X: http://apple.stackexchange.com/a/146851 http://apple.stackexchange.com/a/146851 It provides a one-step copy and paste into the terminal to download, patch and compile bash from apple.com and gnu.org.
brador 12y ago
So assuming it's an online EC2 server not-updated LAMP stack with an empty cgi folder and a lone html page with hello world. Is that vulnerable to bash exploitation in any way?
- dfranke 12y ago
  Probably not, unless there's something really weird in your Apache config.
lambda 12y ago
You missed one of the big ones, DHCP. dhclient calls dhclient-script with attacker controlled environment variables, and on several Linux distros I checked, dhclient-script explicitly uses Bash, so even Debian and Ubuntu, which use dash as sh, are vulnerable.
- dfranke 12y ago
  Someone else already pointed this out in my comments section. I'm working on an update.
X-Istence 12y ago
This of course assumes that bash is set as the default shell for those users all those programs run under. None of my systems have bash installed, thus they aren't vulnerable. FreeBSD by default does not ship with bash, and unless it is specifically installed for 3rd party software use, it is not required for anything, and certainly won't be found as /bin/sh... Shell shock is being blown out of proportion, people are worried local machines they use to browse internet are going to get popped when in reality it is only really Linux machines that have bash as the default shell that should be worried.
- sophacles 12y ago
  All those osx machines have bash as /bin/sh by default too. It's unclear how often shellouts happen within OSX for various operations.
- nitrogen 12y ago
  Any program that calls a library that calls a program that executes a script with #!/bin/bash could be vulnerable, client or server. There are many ways data can get into an environment variable. For example, a hypothetical encryption library might be a wrapper around /usr/bin/gpg or /usr/bin/openssl, and to avoid having arguments show up in ps or top, it might pass arguments as environment variables. Later a secure e-mail program might use that library to validate a signature from an e-mail, and pass signature data in an environment variable. So that's MacOSX and Fedora owned with /bin/bash as /bin/sh. Say the encryption library used a script written in Bash to do some other processing. That's BSD owned.
  - X-Istence 12y ago
    Except that bash is not installed by default... if bash is not installed how does BSD suddenly become vulnerable?
    - nitrogen 12y ago
      It would have been installed as a dependency of whatever used it in some obscure way.
wesley 12y ago
I've got an old red hat somewhere, without yum and apt-get, what can I do to update bash on there? (RHEL3).
- nitrogen 12y ago
  If that version is no longer supported by RedHat, you can compile the patched bash yourself, but you should really try to upgrade as there are probably other vulnerabilities in other components.
- nknighthb 12y ago
  I've posted what I did (as best as I can recall) here: https://gist.github.com/anonymous/56afdedbf92ea98ba237 https://gist.github.com/anonymous/56afdedbf92ea98ba237 It's entirely possible I forgot something. I haven't built an RPM in years and didn't do it often in the first place. I almost didn't bother now except I can't entirely exclude the possibility that two RHEL3 servers that aren't going anywhere might have an attack vector hidden in them somewhere. Edit: Changed link to fixed gist.
zobzu 12y ago
rather than adding fixup to these (which arent all exactly directly exploitable, and sometimes have dodgy POCs), it'd be nice if we stopped calling the shell at all and when necessary, always wipe the env entirely and parse the user input by allowing a specific white list. these methods were used a decade ago and programs not doing stuff like clearing the env were seen as poorly made programs in need of rewrite. Unfortunately that has changed.
- dkubb 12y ago
  Thank you for mentioning this. What I don't understand is that no one is talking about the responsibility of the programs reading the user input. They have a responsibility to validate anything they receive using a whitelisting approach (i.e. denying anything that doesn't match expected patterns). If a program simply slurps in user input without doing any basic validation according to published RFCs then there's a bug in that program.
js2 12y ago
Always protect your OpenVPN instances with tls-auth, especially if your instance accepts connections from any IP. It prevents the SSL negotiation from even occurring if it doesn't match. It would have protected you from heart bleed, and it protects against shell shock. There is no downside to using it. However, keep in mind that the key file is shared across all clients, so you probably want to change it periodically depending upon how much you trust your clients not to become hostile. You could run multiple server instances on different ports/IPs to subdivide your client base, or when rolling out a new key.
- Wilya 12y ago
  I wish the official OpenVPN howto [0] highlighted this sort of things a bit more. As it is, it provides a clear and easy to follow path to a minimally viable setup, but only mentions many additional security parameters (tls-auth, running as unpriviledged user, chroot, increasing key size) under "Hardening OpenVPN Security", very far down the page, where people probably miss it. And this, even though some of these elements vastly increase the security with little to no downside. [0] https://openvpn.net/index.php/open-source/documentation/howto.html https://openvpn.net/index.php/open-source/documentation/howt...
seanp2k2 12y ago
I feel like the only reasonable thing to do now is to capture all traffic going to a web server and analyze every field for that's that eventually become env vars.
- clarry 12y ago
  Or fix the shell or use another one.
moduloo 12y ago
https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223 CUPS probably too, but no POC seen yet
danielweber 12y ago
Maybe a small note, but the variable needs to start with the bytes "() {", not the characters. For example, () {̀ also triggers the parsing code. That's a ` over the { using Unicode. FWIW, I haven't been able to actually exploit it this way, but referencing that variable in the new shell generates errors, so there might be something there: bash: () {̀ :;}; echo vuln2: invalid variable name for name reference
AsakiIssa 12y ago
I wonder if anyone has thought of any indirect vectors? Imagine a Windows based virus that can scan a private network and use the shellshock exploit to infect never-before-seen unix devices with a HTTP service?
deleted 12y ago
[deleted]
moduloo 12y ago
suphp might be exploitet, but only with stupid settings https://8ack.de/guides/suphp_shellshock https://8ack.de/guides/suphp_shellshock

142 points by dfranke 12y ago

Somewhat ironic for all the noise made about qmail that many configurations of it are vulnerable. I wonder if Bernstein will be paying out that $1000 reward, and if so, to who See section 1.3: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf

dfranke 12y ago
The qmail bounty explicitly disclaims "bugs outside of qmail", which this one clearly is. So, no.
- kag 12y ago
  Why it's not exploitable without the shellshock-vulnerable bash, you could argue that qmail is not validating the input in accordance with the RFCs. In fact, that's one of the things I said here: http://marc.info/?l=qmail&m=141183309314366&w=2 http://marc.info/?l=qmail&m=141183309314366&w=2
  - panic 12y ago
    Input validation is an orthogonal issue here, since bash doesn't know anything about RFC821/RFC2821, doesn't expect data in that format, and doesn't make any guarantees about what it will or won't do on such data. The only reasonable policy for a shell to follow is to be entirely input-agnostic and never execute code based on the contents of an environment variable (regardless of which RFCs the contents conform to).
    - kag 12y ago
      Of course bash doesn't know and shouldn't know about the SMTP RFCs. Yes, bash shouldn't execute code in variables. I was talking about input validation in qmail itself, not bash. Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.

_delirium 12y ago

One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that invoke /bin/sh. If bash is not installed as /bin/sh, as is the case on Debian and Ubuntu, do any of these (inetd, exim, etc.) still explicitly call it? Put differently, is this mainly an issue for distributions that ship bash as /bin/sh? Or do users of distributions like Debian also need to worry about common system services setting bash shell variables? Maybe I'll try to answer that by pulling a bunch of Debian source packages and grepping for explicit calls to bash...

lambda 12y ago
The one major one I found was the DHCP vulnerability; if you use ifupdown and configure and interface via DHCP, that uses dhclient, which invokes dhclient-script with attacker controlled variables. dhclient-script is explicitly written in bash, so is vulnerable. I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
pja 12y ago
Even if they don't explicitly invoke bash, it's possible that they call a program which calls a program which invokes a bash script somewhere. Debian switched /bin/sh to link to dash a while back, but some maintainers decided to simply change the #!/bin/sh at the top of the shell scripts in their packages to #!/bin/bash rather than remove the bashisms. dhclient is the worst offender in the current kerfuffle, but I'm sure there are others.
- tokenizerrr 12y ago
  They did switch /bin/sh to dash, which is why it seems to me that grepping for "bash" would be quite effective.

patio11 12y ago

On the theory that it is more likely to help HNers than the bad guys: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html http://httpd.apache.org/docs/2.2/mod/mod_ssl.html . Note in particular the part about StdEnvVars. The docs say it is off by default, but it is actually on in a lot of common deployment scenarios, for example if most of your apache configs were sourced from the big "apt-get install foo bar baz" line everyone copies from a blog post to get a working LAMP installation on an Ubuntu box. I have not POCed this yet, but if I were trying to, I'd first try to make a client certificate with a highly non-standard Distinguished Name. It doesn't particularly matter if it fails validation as long as it doesn't fail in such a way that Apache dies before passing your information deeper into the guts of the web app. After that point you're just looking for e.g. any page or library in the web app you can coerce to do a system() call or similar. While I was poking around in my own apps something like system(...) in Ruby on Ubuntu actually called /bin/sh rather than bash, but I think that is probably not the case for every combination of stack and distro.

hawkice 12y ago
Slightly more precisely: /bin/sh on ubuntu points to Dash, which is substantially more minimal than bash. Probably not chosen for security (I imagine speed was on their mind), but good either way.
- stakent 12y ago
  In Debian /bin/sh points to dash too.
bch 12y ago
Re: /bin/sh versus /bin/bash (or similar) - note that many Linux systems link /bin/sh -> /bin/bash, so seeing /bin/sh, or knowing that's what system() calls, is not sufficient information on its own to determine your risk.
- patio11 12y ago
  Yep. More broadly, I think the most sensible strategy for determining whether a system is at risk is "If it has bash and isn't airgapped assume that it's vulnerable because it is highly likely someone will find the vector you overlook."

idorosen 12y ago

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and the CVE-2014-7169 patch. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched https://github.com/ido/macosx-bash-92-shellshock-patched Binary releases are here: https://github.com/ido/macosx-bash-92-shellshock-patched/releases https://github.com/ido/macosx-bash-92-shellshock-patched/rel... ...including a .pkg file that can be installed with a double-click. Instruction here: https://github.com/ido/macosx-bash-92-shellshock-patched/blob/master/README.md https://github.com/ido/macosx-bash-92-shellshock-patched/blo...

JackC 12y ago
This appears (to me) to be another good temporary fix for OS X: http://apple.stackexchange.com/a/146851 http://apple.stackexchange.com/a/146851 It provides a one-step copy and paste into the terminal to download, patch and compile bash from apple.com and gnu.org.

brador 12y ago

So assuming it's an online EC2 server not-updated LAMP stack with an empty cgi folder and a lone html page with hello world. Is that vulnerable to bash exploitation in any way?

dfranke 12y ago
Probably not, unless there's something really weird in your Apache config.

lambda 12y ago

You missed one of the big ones, DHCP. dhclient calls dhclient-script with attacker controlled environment variables, and on several Linux distros I checked, dhclient-script explicitly uses Bash, so even Debian and Ubuntu, which use dash as sh, are vulnerable.

dfranke 12y ago
Someone else already pointed this out in my comments section. I'm working on an update.

X-Istence 12y ago

This of course assumes that bash is set as the default shell for those users all those programs run under. None of my systems have bash installed, thus they aren't vulnerable. FreeBSD by default does not ship with bash, and unless it is specifically installed for 3rd party software use, it is not required for anything, and certainly won't be found as /bin/sh... Shell shock is being blown out of proportion, people are worried local machines they use to browse internet are going to get popped when in reality it is only really Linux machines that have bash as the default shell that should be worried.

sophacles 12y ago
All those osx machines have bash as /bin/sh by default too. It's unclear how often shellouts happen within OSX for various operations.
nitrogen 12y ago
Any program that calls a library that calls a program that executes a script with #!/bin/bash could be vulnerable, client or server. There are many ways data can get into an environment variable. For example, a hypothetical encryption library might be a wrapper around /usr/bin/gpg or /usr/bin/openssl, and to avoid having arguments show up in ps or top, it might pass arguments as environment variables. Later a secure e-mail program might use that library to validate a signature from an e-mail, and pass signature data in an environment variable. So that's MacOSX and Fedora owned with /bin/bash as /bin/sh. Say the encryption library used a script written in Bash to do some other processing. That's BSD owned.
- X-Istence 12y ago
  Except that bash is not installed by default... if bash is not installed how does BSD suddenly become vulnerable?
  - nitrogen 12y ago
    It would have been installed as a dependency of whatever used it in some obscure way.

wesley 12y ago

I've got an old red hat somewhere, without yum and apt-get, what can I do to update bash on there? (RHEL3).

nitrogen 12y ago
If that version is no longer supported by RedHat, you can compile the patched bash yourself, but you should really try to upgrade as there are probably other vulnerabilities in other components.
nknighthb 12y ago
I've posted what I did (as best as I can recall) here: https://gist.github.com/anonymous/56afdedbf92ea98ba237 https://gist.github.com/anonymous/56afdedbf92ea98ba237 It's entirely possible I forgot something. I haven't built an RPM in years and didn't do it often in the first place. I almost didn't bother now except I can't entirely exclude the possibility that two RHEL3 servers that aren't going anywhere might have an attack vector hidden in them somewhere. Edit: Changed link to fixed gist.

zobzu 12y ago

rather than adding fixup to these (which arent all exactly directly exploitable, and sometimes have dodgy POCs), it'd be nice if we stopped calling the shell at all and when necessary, always wipe the env entirely and parse the user input by allowing a specific white list. these methods were used a decade ago and programs not doing stuff like clearing the env were seen as poorly made programs in need of rewrite. Unfortunately that has changed.

dkubb 12y ago
Thank you for mentioning this. What I don't understand is that no one is talking about the responsibility of the programs reading the user input. They have a responsibility to validate anything they receive using a whitelisting approach (i.e. denying anything that doesn't match expected patterns). If a program simply slurps in user input without doing any basic validation according to published RFCs then there's a bug in that program.

js2 12y ago

Always protect your OpenVPN instances with tls-auth, especially if your instance accepts connections from any IP. It prevents the SSL negotiation from even occurring if it doesn't match. It would have protected you from heart bleed, and it protects against shell shock. There is no downside to using it. However, keep in mind that the key file is shared across all clients, so you probably want to change it periodically depending upon how much you trust your clients not to become hostile. You could run multiple server instances on different ports/IPs to subdivide your client base, or when rolling out a new key.

Wilya 12y ago
I wish the official OpenVPN howto [0] highlighted this sort of things a bit more. As it is, it provides a clear and easy to follow path to a minimally viable setup, but only mentions many additional security parameters (tls-auth, running as unpriviledged user, chroot, increasing key size) under "Hardening OpenVPN Security", very far down the page, where people probably miss it. And this, even though some of these elements vastly increase the security with little to no downside. [0] https://openvpn.net/index.php/open-source/documentation/howto.html https://openvpn.net/index.php/open-source/documentation/howt...

seanp2k2 12y ago

I feel like the only reasonable thing to do now is to capture all traffic going to a web server and analyze every field for that's that eventually become env vars.

clarry 12y ago
Or fix the shell or use another one.

moduloo 12y ago

https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223 CUPS probably too, but no POC seen yet

danielweber 12y ago

Maybe a small note, but the variable needs to start with the bytes "() {", not the characters. For example, () {̀ also triggers the parsing code. That's a ` over the { using Unicode. FWIW, I haven't been able to actually exploit it this way, but referencing that variable in the new shell generates errors, so there might be something there: bash: () {̀ :;}; echo vuln2: invalid variable name for name reference

AsakiIssa 12y ago

I wonder if anyone has thought of any indirect vectors? Imagine a Windows based virus that can scan a private network and use the shellshock exploit to infect never-before-seen unix devices with a HTTP service?

deleted 12y ago

[deleted]

moduloo 12y ago

suphp might be exploitet, but only with stupid settings https://8ack.de/guides/suphp_shellshock https://8ack.de/guides/suphp_shellshock