3 ms·
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,
by 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 agoIf 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 agoit could be a bug in the sh compatibility mode
- claudius 12y agookay, 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 agoIt's not that you shouldn't test other things, but as one single test this was much better than calling directly to bash.