I was actually just thinking another way to use this might be to have ssh pass x='() {:;}; echo vulnerable' as a variable to remote systems, that way whenever you login to a remote system, it just tells you whether it is vulnerable or not on login.
Most sshd daemons aren't configured to accept just any environment variables, they limit exposure with an AcceptEnv directive in the sshd configuration file (/etc/ssh/sshd_config on most Linux versions. This means that
SSH can be configured to lock down which commands the user can run; this is common in combination with e.g. gitolite [gitolite.com] for letting people push to a git repository without giving them full shell access. Anybody with access to such a server can now run arbitrary local commands
Or, more easily: the exploit string could be packed into the TERM variable, which almost all ssh's and even telnet daemons pass on the the shell:
env TERM='() {:;}; echo vulnerable ssh some_user@some_server'
Suppose you are a guest at my house and you want to ssh into your own computer at your house. I say no problem and I create you a user account on my computer which you then use to ssh to your computer.
Still don't think it's a problem?
Of course I could also have a key logger installed.
Yes but the intent wasn't to exploit so much as to have a way to raise a flag when connecting to a vulnerable system, so as to know it still needs updating.
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x' This is a test
or just
This is a test
then your server is patched successfully. Whether or not the error message displays depends on bash configuration. I have three CentOS 6.5 servers that I manage in my house and one in the cloud. On the 3 64-bit machines which were original installs it generates the error message after patching. On the 1 32-bit machine which was upgraded from a previous
$ env 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
$ bash --version bash --version GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu) This is from my Debian stable box.
That's good. The version number means nothing since Debian backported the fix rather than upgrading bash completely, but the check above didn't say vulnerable so you're clear.
Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability. Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.
Pascal is not a high-level language.
-- Steven Feiner
Test string here: (Score:5, Informative)
env x='() {
Re: (Score:0)
Re:Test string here: (Score:5, Informative)
SSH into your host.
from the bash prompt just paste the above string.
i.e. :;}; echo vulnerable' bash -c "echo this is a test"
user@host $env x='() {
--------------------
If you see:
vulnerable
this is a test
Then you are vulnerable and need to update your system.
If all you see is:
this is a test
Then you are ok.
Re: (Score:3)
I was actually just thinking another way to use this might be to have ssh pass x='() { :;}; echo vulnerable' as a variable to remote systems, that way whenever you login to a remote system, it just tells you whether it is vulnerable or not on login.
Re:Test string here: (Score:5, Informative)
env x='() {
probably won't work on most systems but
env LC_FRED='() {
will if the server is configured to accept the LC_* environment variables with the AcceptEnv directive in sshd_config.
Re: (Score:2)
SSH can be configured to lock down which commands the user can run; this is common in combination with e.g. gitolite [gitolite.com] for letting people push to a git repository without giving them full shell access. Anybody with access to such a server can now run arbitrary local commands
Re: (Score:2)
Re: (Score:2)
Suppose you are a guest at my house and you want to ssh into your own computer at your house. I say no problem and I create you a user account on my computer which you then use to ssh to your computer.
Still don't think it's a problem?
Of course I could also have a key logger installed.
Re: (Score:2)
Yes but the intent wasn't to exploit so much as to have a way to raise a flag when connecting to a vulnerable system, so as to know it still needs updating.
Re: (Score:2)
Um...please tell me this is Poe's law at work and you're not a complete idjit [sic].
Re: (Score:2)
or just
then your server is patched successfully. Whether or not the error message displays depends on bash configuration. I have three CentOS 6.5 servers that I manage in my house and one in the cloud. On the 3 64-bit machines which were original installs it generates the error message after patching. On the 1 32-bit machine which was upgraded from a previous
Got the bash update this mawning for my Debian... (Score:2)
$ env 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
$ bash --version
bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
This is from my Debian stable box.
Is that good or bad? :O
Re: (Score:2)
That's good. The version number means nothing since Debian backported the fix rather than upgrading bash completely, but the check above didn't say vulnerable so you're clear.
Re: (Score:2)
Thank you, sir. Good job to Debian team on releasing the fix!
Re: (Score:2)
Take a look again at the command you just ran. You're still invoking bash.
Re: (Score:2)
Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability.
Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.