5

I am using Fedora 20 on two machines.

Having read about the Shellshock vulnerability, just now at 1100ish UTC on September 26th 2014, in UK, after a yum update bash to protect against it, I tried this recommended testmodes:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

and, in both user and su modes, got this result on one machine:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test

On the other I got simply:

this is a test

Please: have I succeeded on both machines, or should I worry?


In response to @terdon's comment I got this result:

[Harry@localhost]~% env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
echo vuln
cat: echo: No such file or directory
[Harry@localhost]~%

Not sure what it means, though.


Just to make it clear, I am puzzled by the warning, and also the differences between the two machines. I have had another close look at the warning message. It might be that, on the machine without the error message, I entered the command with "copy and paste": on the other I typed it in and got the warning, and I now see that the warning quotes the final 'x' as `x' (note the "back tick"). That machine has an american keyboard that I cannot yet change to UK layout, but there is another question entirely.

Pursuing this on the 'net this LinuxQuestions.org thread discusses it and it appears that both are safe.

  • 6
    Please post the output of env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :(". This should check whether you are still vulnerable to the newer CVE-2014-7169. – terdon Sep 26 '14 at 11:44
  • As far as I understood your question correctly you are asking why in one case the warning is displayed and in the other case not. Right? – Chrispie Sep 26 '14 at 13:01
  • You should clarify in your question, that you are interested in the meaning of the BASH-warning and not in the general mechanics of the "Shellshock Test-command". – Chrispie Sep 26 '14 at 13:11
  • Thanks Chrispie, yes, as well as reassurance that I have cured the vulnerability, I am puzzled by the warning. It might be that, on one machine I entered the command with "copy and paste", no warning: on the other I typed it in and got the warning, and I see that, there the warning quotes the 'x' as `x' (note the "back tick"). That machine has an american keyboard that I cannot yet change to UK layout. – Harry Weston Sep 26 '14 at 13:12
  • Comments crossed, sorry. I thought it was implicit in my question that I would have liked answers to both of these. Perhaps answers to both would have been quicker and easier than wondering which I was asking. – Harry Weston Sep 26 '14 at 13:15
7

You have done it right.
Your systems are secure and not vulnerable from this exploit.

If your system would not be secure, the output of the command would be:

vulnerable
this is a test

but since your output is

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test

you are safe.

If you did this yesterday, please consider running yum update bash today, too as the fix from yesterday is not as good as the one released today.


EDIT (as OP requested more information)

I can also calm you on the newer vulnerablility. Your system already has the new fix installed.

If you'd had the output

echo vuln
still vulnerable :(

you'd be still vulnerable.

Now I cannot give you answer to how the exploit exactly works, I mean by that that I cannot tell you what exactly happens and what the differences are between the first and the second exploit. But I can give you a simplified answer to how the expoit works.

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
"Does nothing else" than saving a bit of executable code in an environmental variable that will be executed every time you start a bash-shell.
And a bash-shell is started easily/often. Not only by yourself but also a lot of programs need a bash to fulfill theyr work. Like CGI for example.

If you would like to have some deeper read about this exploit, here is a link to red hats security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

  • Thanks, Warren young, for that. I included the time "1100ish UTC on September 26th 2014, in UK" in my question to take account of this possibility. So, please, is there a later update? I have not yet marked an answer as accepted, as none have explained the error message. – Harry Weston Sep 26 '14 at 13:05
  • 1
    Thanks derty. The reference you quote to "red hats security blog" is where I copied the fix from originally. – Harry Weston Sep 26 '14 at 15:42
3

If it wasn't fixed you should have read vulnerable after both attempts.

1

The first output is that of a fixed bash. The second one doesn't show the warning added by the patch fix, but shows correct behavior (it isn't vulnerable). Maybe the second machine isn't really using bash, or the distribution used a slightly different patch (eg. one disabling exportable functions). Can you provide the output of bash --version for both machines?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.