5 ms·

The second test there env X='() { (a)=>\' sh -c "echo date"; cat echo calls sh rather than bash, which is likely not linked to bash on Debian-y systems. Fu

• muyuu 12y ago
  If it's not bash it shouldn't run that. It's not about detecting bash, but the vulnerability.
  • yebyen 12y ago
    But if your login shell isn't bash, and the test itself doesn't run bash, at what point are you actually testing bash (the software that is known to have at least once contained this vulnerability)?
    • muyuu 12y ago
      It doesn't matter. If you find another shell that is vulnerable it's still a problem. Apparently it's only bash though. sh will run whatever is pointed by the symlink. It's a good idea to try that than relying on bash being in its place and that an attacher hasn't masked it. Apache and other daemons will run sh, so that's what you want to try.
      • yebyen 12y ago
        In spite of all the good advice I've got about this vuln having come from HN, I feel like all of the time people are spending trying to produce the best snippet and correct each other (ourselves) to check for vulnerability is like one big circlejerk. I'm not sure who downvoted you, but I don't think you earned it. Every short piece of advice in each of these threads is likely to be part wrong, especially whenever taken out of context.
    • ZoFreX 12y ago
      If you have bash installed, but it isn't the system bash (/bin/sh), and none of your scripts explicitly call bash or have a bash shebang, then you aren't vulnerable. However, if bash is your /bin/sh, then even a script that appears to have nothing to do with bash but happens to call something like system() will invoke bash.
      • claudius 12y ago
        But that line was intended to test whether your installed version of Bash is vulnerable to this attack. You don’t do that by solely calling /bin/sh. Of course, you can also check /bin/sh explicitly if you are worried about extra copies of Bash hiding there.
        • muyuu 12y ago
          If the test works, you are using bash and it's still vulnerable. That's all you need to know. By changing the call you make the test less effective for the reasons explained above.
          • RubyPinch 12y ago
            it could be a bug in the sh compatibility mode
          • claudius 12y ago
            okay, let me make this little table. "VULN" denotes the test above (with sh rather than bash) detecting a vulnerable situation, "OK" means the test detects no vulnerability. sh → bash | bash vulnerable | VULN sh → bash | bash fixed | OK sh → dash | bash vulnerable | OK sh → dash | bash fixed | OK Why do you want to only test the first but not the third case? You can perfectly well have /bin/sh linked to dash and still be vulnerable, because e.g. dhclient calls a Bash script.
            • muyuu 12y ago
              It's not that you shouldn't test other things, but as one single test this was much better than calling directly to bash.
• Zikes 12y ago
  Pales in comparison to curl https://shellshocker.net/fixbash | sh
  • windsurfer 12y ago
    Are you vulnerable to giving attackers shell access on your computers? Pipe this into your shell and find out!
    • RAB1138 12y ago
      OK so I'm not the only person deeply troubled by their generous offer to remotely test my servers for vulnerability. Thank god they included the safe 'at-home' test kit
      • Volundr 12y ago
        Not only that, but it's going to ask for your sudo password too. No reason to be leary of that ;-)
    • txutxu 12y ago
      Also... Are you in doubt if your server is vulnerable? just create this simple bash CGI file, and then get it called by us! Just in case your apache did not have any bash CGI as usual :)
  • wglb 12y ago
    Good grief. What could possibly go wrong. (I had a rubber stamp made up with this saying. It is part of my black bag.)