221–230 of 296 posts
For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched
Earlier quoted context omitted.
Apache isn't setting CGI variables using the shell. It may call a shell (indirectly or directly) when executing the CGI script.
So does that mean that running a bash script under cgi doesn't inherently expose you to the vulnerability, you're vulnerable only if the bash script called invokes a shell in a sub-process?
Earlier quoted context omitted.
Apache isn't setting CGI variables using the shell. It may call a shell (indirectly or directly) when executing the CGI script.
So does that mean that running a bash script under cgi doesn't inherently expose you to the vulnerability, you're vulnerable only if the bash script called invokes a shell in a sub-process?
If you're running a php/perl/python/ruby script as a cgi script in your web server, and that script calls system() or some variant thereof (backticks in perl, os.system in python), then you're vulnerable to this.
Not many people does that, but those who do won't be things you think of as web applications. They're going to be web control panels you installed and forgot about, or cheap home routers that nobody knows who made the firmware to.
My experiments with
#!/usr/bin/env -i sh
and
#!/usr/bin/env - sh
...have not obtained what I'm after.
The problem being that functions take precedence over names in the file system, so
bash-4.2$ env '/bin/cp=() { echo oops;}' /bin/sh -c '/bin/cp /tmp/foo /tmp/bar'
oopsEarlier quoted context omitted.
Bash is a shell, part of it's purpose is to deal with enviroment variables. The bug here is that the parser is getting confused, the feature being abused here is being able to declare functions as part of an enviroment variable, which is used to transfer functions to subshells in bash. Now this itself is fine, but since the parser gets confused it also executes commands after the function definition.
I honestly can't see why this is "fine"... I understand it's not the security critical bug, but feeding all environment variables into some sort of interpreter...?!? Ok, bash needs to transfer function definitions to child processes in order to implement something called inherited functions, and I guess you could argue that an environment variable is a reasonable place to store them. But WHY THE HELL does bash have t…
Does anybody has steps what to do really as a sysadmin? Do I only need to install newest bash (on Linux systems) or do I also need to restart daemons like nginx/apache etc. ?
The vulnerability only affects bash when it is parsing environment variables, when it is just starting. So if a process is already running, it's not vulnerable and you don't have to restart it. You should definitely apply the patch from Wednesday, but be aware there is a related vulnerability that has no patch yet. Add the configuration from this page https://access.redhat.com/solutions/1207723 to your Apache or ngin…
Earlier quoted context omitted.
Odd. I am running quite old software: echo $0 -> bash ls -l /bin/sh -> /bin/bash GNU bash, version 3.1.17(2)-release Apache/2.2.25 And I couldn't reproduce the vurnerability in a perl cgi script unless I had explicitly referenced an environment variable in the system() call like I posted above. I thought all versions are vurnerable. #test-cgi.pl use strict; use warnings; use CGI; print "Content-Type: text/plain\n\n";…
From "man perlfunc" unser "system": If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more effic…
Earlier quoted context omitted.
"could some benevolent person use the bug to cause remote systems to run something like " That's not benevolent that's intrusion. Nobody has the right to take it upon themselves to determine what someone else should be doing in this case. I would imagine that an action like that would also clearly violate a law or two (I'm sure others more knowledgeable could cite the law).
At the risk of participating in a philosophical debate, I pose a classic counterexample: You encounter a car parked on the side of the road in the middle of nowhere. Its windows are rolled down. Storm clouds are rumbling nearby and it's obviously about to rain. There's nobody around but you. Do you also consider rolling up the windows to be intrusion? Personally I'd feel an ethical obligation to help the stranger out…
Earlier quoted context omitted.
The vulnerability only affects bash when it is parsing environment variables, when it is just starting. So if a process is already running, it's not vulnerable and you don't have to restart it. You should definitely apply the patch from Wednesday, but be aware there is a related vulnerability that has no patch yet. Add the configuration from this page https://access.redhat.com/solutions/1207723 to your Apache or ngin…
This isn't always true. Frequently sub-shells are started without people really knowing, like with backticks or parenthesis.