Thanks Michael, Thanks for the demonstration. Indeed the details you have demonstrated gives the issue a much more accurate description of it. Indeed I'm not aware of all the options to exploit the vulnerabilities since my experience is lower then many others. From the other hand once you have some grasp on the basic affected scenarios (which should be listed somewhere) some of them can be prevented using simple means while others cannot. Aside this specific CVE it's common knowledge that the CGI interface is one of the most vulnerable interfaces there was in many years with relation to this or not. Specifically for SSH I have seen in the past couple security examples that prevents the mentioned issue from even being there. Maybe my words was not clear enough so I will try again: *I do understand the vulnerbilities* More then just that, I have seen couple scripts in the past that got hit by similar ideas. One of the amazing examples is that a cgi script runs under using system() + sudo while using some environmental variables. Indeed also if the script is not running under sudo it can still cause harm to one and more web systems. The basic fact that some cisco devices has these bash versions and also vyatta\vyos and others, puts them in a very weird situation. For many years many systems are out-there on the Internet and still they were safe. For the cases that the admin or a user wants to do something with the server..... Imagine this: Cell Phone rings for Eliezer: "hello, we are having a trouble here what should we do?" Eliezer: "run a backup of directory '/home/user_x_y_z' and only then try to do this or that" The other side: "oops" Eliezer: "What oops?" The other side: "I suddenly do not have access to tar for some reason and I'm getting errors on the monitoring system about this host and another one.." Eliezer couple minutes later at the place: "Why do all the files on the server has a user ownership of x_y_z???" Eliezer walk throw the history logs... second .. two.. Eliezer: "Eureka.. There is no history log since the command was entered using a space at the beginning of the line" Ho well another CVE on bash that was never fixed in time. I hope my humor is not darker then black. All The Bests and Thanks, Eliezer On 09/28/2014 01:28 AM, Michael Fincham wrote:
I don't think you have understood this bug completely - the underlying assumption that it is safe to set environment variables to arbitrary values is wrong - this (at least -6271) is a bug in the way the variables are parsed internally in bash potentially leading to code execution. "injection of functions into the bash environment" is an intentional feature of bash, having those functions execute code while being defined is a parser bug 8^)
Here is a scenario:
You have an SSH server with this configuration for a user in their authorized_keys file:
command="/opt/fincham/do-nothing" ssh-rsa AAAAB3NzA..Dxq= user(a)example.com
And `/opt/fincham/do-nothing' looks like this:
#!/bin/bash
/bin/false
SSH will force `/opt/fincham/do-nothing' to run when the user connects, and this script is clearly incapable of doing anything exciting.
However in this situation, SSH will set a variable `SSH_ORIGINAL_COMMAND' in the environment of the spawned shell to a value supplied by the connecting user (e.g. if the user runs "ssh server.example.com foo" the value of SSH_ORIGINAL_COMMAND will be "foo"). It is easy to see that, by design, this does not matter, as nothing in the script examines or uses this environment variable.
This is where the seriousness of the bug comes in - when the `bash' process starts it will parser the environment, and in doing so it is possible to exploit bash's parser to execute arbitrary code /while it is merely examining the contents/ of that environment.
For instance if I connect with:
ssh server.example.com "{ :;}; /some/malicious/command"
My script that previously could only call `/bin/false' will now run `/some/malicious/command' as soon as bash is called by OpenSSH.
Now think about how many places where a user can set an environment variable (for instance, as intended functionality of CGI, to pass e.g. HTTP_COOKIE values in to the CGI script) and where bash will be called subsequently, either intentionally or implicitly by e.g. system().