Don't forget to update your docker containers and restart them.
CVE-2014-6271: Remote code execution through bash
211–220 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#212All the explanations of why this is bad seem to involve CGI. Didn't the CGI interface die in the 90's? Who uses that nowadays?
Re: CVE-2014-6271: Remote code execution through bash
#213Earlier quoted context omitted.
So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?
I like the DHCP attack vector which was mentioned in the RedHat posting. DHCP clients invoke shell scripts.
Just curious, how long can a wireless SSID be?
I ask because I've seen SSIDs with meaningful characters ();? cause trouble with some network managers. I presumed at the time that this was due to the SSID string being passed as an argument to some script.
I've encountered this on my old Android phone and my old Debian laptop. I encountered it often because a friend of mine used to have an emoticon in the SSID for his home router. (Really annoying! I couldn't connect to anything when his router was in range.)
Note: it could very well have been a different problem. I didn't investigate.
Re: CVE-2014-6271: Remote code execution through bash
#214Earlier quoted context omitted.
Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string. GET / HTTP/1.0 User-Agent: () { :; }; rm -rf / Restricted SSH accounts (like the ones used by GitHu…
"A CGI script written in bash" You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.
That's ridiculous. You may as well say that every time you put a python script up, you're exposing the entire Python runtime and deserve to get 'pwned'.
The scope of the risk is limited to script that you write, whether bash or Python.
Re: CVE-2014-6271: Remote code execution through bash
#215Earlier quoted context omitted.
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your…
The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.
> the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting.
Maybe not in C, but they are a drop-in replacement in just about every scripting language. Perl, Ruby, Python, all have nice high level calls that mostly mimic system() but use execve underneath—You simply pass system() multiple arguments instead of a single string. `system("")` in your production web app server code is almost certainly incorrect.
Sadly I think PHP still doesn't have this.
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Very true, but think about whether you really need a shell to launch your command (are you using any shell features?). If not, why not just launch the command directly?
Re: CVE-2014-6271: Remote code execution through bash
#216Wanted to share the simple Ansible script we used to patch CVE-2014-6271 at npm: https://github.com/npm/ansible-bashpocalypse
Re: CVE-2014-6271: Remote code execution through bash
#217Earlier quoted context omitted.
You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.
Because of the way cgi works you could just set a user agent or other http header to contain an 'rm' or'nc' command or something in to download and run an attack tool. E.g. You could run netcat to listen on a port or connect out to an attacker's system to provide a connection into an otherwise firewalled database server
Yes, you're right. We have perl running on our server, and I just verified that it is vulnerable if any shell scripts are run from perl. However I just quickly switched on modperl, and I verified that it is now not affected. (According to Redhat, mod_perl and php are not affected, but it's good to verify).
Re: CVE-2014-6271: Remote code execution through bash
#218Is it just me, or are the patches "fixing" the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privi…
It's not just you. The fact that an environment variable can override e.g. "git" to do something else is a real problem requiring separate protection. However, that's effectively PATH injection rather than code injection so it's already addressed in many cases.
Except that most environments already filter out attempts to control PATH, LD_LIBRARY_PATH, and similar; they don't filter out "git".
Re: CVE-2014-6271: Remote code execution through bash
#219Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable:
$ echo $BASH_VERSION
3.2.51(1)-release
$ x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
$
$ echo $BASH_VERSION
4.3.25(1)-release
$ x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
$