6 ms·

Shellshock BASH Vulnerability Tester

82 points by ericclemmons 12y ago

ericclemmons 12y ago
There have been a lot of articles about ShellShock, but this site is the most straightforward I've found for developers (not familiar with Bash, security, etc.) to test & fix Bash.
knave 12y ago
Particularly useful is the patch from source. I've already used it for an Ubuntu 11.04 server (past end of life for apt support), and am about to start on some RHEL servers
ck2 12y ago
Just a caution that newegg has a registered trademark on "shell shocker" - not sure if that is a problem or not.
- chrisan 12y ago
  Given Newegg's fights on patent trolls and that shellshocker.net is about helping people secure themselves vs selling electronics... I would think they are safe from litigation /ianal edit: Maybe Mattel will however :) http://trademarks.justia.com/857/91/shell-shocker-85791354.html http://trademarks.justia.com/857/91/shell-shocker-85791354.h...
  - brador 12y ago
    It's still a trademark and if they want to keep it they have to show they're willing to protect it, else they could lose it.
    - itsame 12y ago
      Not a lawyer, but as I understand it, trademarks often cover only specific market categories. That is, someone can in some cases use a trademark in a market category that the original trademark owner does not operate (e.g. Company1 using BrandA sells only consumer electronics, some Company2 can actually later use BrandA to sell baby diapers). As long as BrandA isn't sufficiently famous and there is no risk of confusion or brand dilution, then Company2 isn't necessarily going to get in trouble. Of course, determining where the line gets drawn probably isn't always a matter of checking off items in some checklist (gray areas, etc.). Nevertheless, in the case of Newegg's Shell Shocker deals, it doesn't seem to me like it overlaps with this site's intent (vulnerability testing). Only overlap I see is that it's something that's operated over the Internet. Would be far-fetched to say that this site is capitalizing on Newegg's brand goodwill to... get people to test for server/machine vulnerabilities. Also... "It is not necessary for a trademark owner to take enforcement action against all infringement if it can be shown that the owner perceived the infringement to be minor and inconsequential. This is designed to prevent owners from continually being tied up in litigation for fear of cancellation."[1] So just because Newegg has a trademark doesn't mean it immediately and invariably has an obligation to enforce it at the threat of losing it. [1] http://en.wikipedia.org/wiki/Trademark#Maintaining_rights http://en.wikipedia.org/wiki/Trademark#Maintaining_rights
      - lutusp 12y ago
        > Not a lawyer, but as I understand it, trademarks often cover only specific market categories. That is, someone can in some cases use a trademark in a market category that the original trademark owner does not operate (e.g. Company1 using BrandA sells only consumer electronics, some Company2 can actually later use BrandA to sell baby diapers). As long as BrandA isn't sufficiently famous and there is no risk of confusion or brand dilution, then Company2 isn't necessarily going to get in trouble. This is true, and when a trademark holder attempts a legal action, they have to show a possibility for public confusion and loss of business to the "infringer". This is why Apple Music (the Beatles) and Apple Computer were free to coexist for decades -- no prospect for public confusion. By contrast, there's a now-famous case in which someone whose name was McDonald, and who operated a restaurant named "McDonald's", was obliged to rename his establishment after the other, much bigger McDonald's brought legal action on the ground of public confusion. The fact that the man's name was McDonald wasn't sufficient grounds to justify the name. I had a legal tangle which this protected-word issue. I once had a Web page that provided sunrise and sunset times. I foolishly called it "Sun computer". The other Sun Computer quickly threatened legal action for my use of the protected word "sun". No, boys and girls, I'm not making this up: http://www.arachnoid.com/lutusp/sunrise/#The__Sun_Computer__Story http://www.arachnoid.com/lutusp/sunrise/#The__Sun_Computer__...
claudius 12y ago
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. Furthermore, keep in mind http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste and use C-x C-e.
- 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.
ck2 12y ago
This post claims that it is still not fixed and there is a 3rd case: http://seclists.org/oss-sec/2014/q3/741 http://seclists.org/oss-sec/2014/q3/741 http://seclists.org/oss-sec/2014/q3/711 http://seclists.org/oss-sec/2014/q3/711 Was that before the second patch was sent out last night? Or can we expect a third patch this weekend?
- tokenizerrr 12y ago
  The posts you linked are just referring to the actual "feature", not another exploit. This feature is being able to define functions from enviroment variables, and requires the attacker to be able to control both the enviroment variable name & value. If an attack can do this, they can also set LD_PRELOAD and a whole host of other nasty enviroment variables.
chrisan 12y ago
So if you don't run CGI nor run a system command within your code, are you fairly safe? If you do have some gem that runs a system cmd, wouldn't it still require url input to get passed down to that command? I'm not advocating NOT upgrading your systems, but still fuzzy on the attack vector if this test requires I upload a cgi script
- schwag09 12y ago
  No, DHCP has been proven vulnerable on some systems. So, a system can be exploited by this bug just by connecting to a LAN (e.g. wifi network). Any protocol or service that runs via BASH is vulnerable. CGI is currently the largest and easiest attack vector to test for.
  - brador 12y ago
    So assuming it's an online EC2 server LAMP stack with an empty cgi folder and a lone html page with hello world. Is that vulnerable to this exploit?
    - tych0 12y ago
      Yes.
      - hnha 12y ago
        remotely? how?
korzun 12y ago
> Possibly vulnerable. This could mean that the server is not at all vulnerable, or we just couldn't detect it as being vulnerable. They should just leave the last part "We couldn't detect it as being vulnerable."
shellshocker 12y ago
I'm taking all of your comments into consideration. I've made two updates already: Removed "This could mean that the server is not at all vulnerable" from the warning messages. Fixed the second exploit to be bash, not sh.
- PabloFanque 12y ago
  Your site currently (2pm EST) lists two exploits, but omits a third variant which "Mitchell" posted in your site's comments 8 hours ago. I've tested two fully updated Ubuntu servers. Both are not vulnerable to the two exploits you posted, but both are vulnerable to the exploit listed in Mitchell's comment. I suggest you post Mitchell's variant prominently as well. The two exploits you've posted: 1. env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 2. env X='() { (a)=>\' bash -c "echo date"; cat echo The third variant Mitchell posted in his comment: 3. env -i X=' () { }; echo hello' bash -c 'date' The systems I've tried these on both have been updated with "sudo apt-get update"; "sudo apt-get dist-upgrade". The systems are: A. Ubuntu 12.04.5 LTS, running Bash version 4.2.25(1)-release (x86_64-pc-linux-gnu) B. Ubuntu 10.04.4 LTS, running version 4.1.5(1)-release (x86_64-pc-linux-gnu)
  - plorg 12y ago
    My updated 14.04 (bash version 4.3.11(1)-release) doesn't appear to be vulnerable to this third exploit.
kazinator 12y ago
I suspect is no need for the "env" command in these examples. That is to say, rather than env X='() { (a)=>\' bash -c "echo date"; cat echo just X='() { (a)=>\' bash -c "echo date"; cat echo That is to say, the shell already has the "env" functionality built in: VAR1=value1 VAR2=value2 ... VARN=valuen command arg ...
spydum 12y ago
When building bash (at least for some variants of Fedora), don't you need to specify the prefix as / so that it copies to /bin? Otherwise, I think it's just installed to $ac_default_prefix/bin, which is usually /usr/local/bin, leaving your old vulnerable one still in /bin/bash ./configure --prefix=/
- shellshocker 12y ago
  Updated! Thanks for that.
tpfister 12y ago
This patch script doesn't seem to fix CVE-2014-7169 (the second exploit) on some distributions. I have confirmed that the vulnerability still works after patching with Debian etch and lenny installations. I have issued an updated patcher script that fixes the patch: https://github.com/tpfister/public/blob/master/patch_shellshock_and_aftershock.sh https://github.com/tpfister/public/blob/master/patch_shellsh... The relevant changes are: # aftershock patch CVE-2014-7169 wget -nv http://tomas.pfister.fi/aftershock_4.3.txt http://tomas.pfister.fi/aftershock_4.3.txt patch -p0 < aftershock_4.3.txt After patching the second vulnerability no longer works: tp@tp:~/src/bash-4.3$ env X='() { (a)=>\' ./bash -c "echo date"; cat echo ./bash: X: line 1: syntax error near unexpected token `=' ./bash: X: line 1: `' ./bash: error importing function definition for `X' date cat: echo: No such file or directory tp@tp:~/src/bash-4.3$
- shellshocker 12y ago
  This is an older, more vulnerable version of BASH. Our script provides 4.3 with fixes, not 3.2
  - tpfister 12y ago
    The script has been updated to bash 4.3.
roozbeh18 12y ago
not sure what this means "hmm... (HTTP/1.1 200 OK): Possibly vulnerable. We couldn't detect it as being vulnerable. We are working on an update to this scanner that will allow for a deeper scan."
- shellshocker 12y ago
  That means that the server could of been vulnerable, but it didn't return that it was.
nounaut 12y ago
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
rasur 12y ago
When the system you're testing replies with a '400 Bad request' (as mine do ;) ), you're probably in "safe" territory, no?
- shellshocker 12y ago
  I would say so yes. Have you tried the exploit cgi listed on the website to test?
  - rasur 12y ago
    I'll have to set something up that actually uses cgi-bin. However, my load-balancer would still kill the request, I suspect. (EDIT: Sorry.. my point being; your site should probably class 400's as 'safe'?)
deleted 12y ago
[deleted]
wiredfool 12y ago
So, to test, they want their CGI put where it will execute in the webroot. And, if you didn't have cgis that were vulnerable before, now anyone can root your machine. So, if your bash is ok, you're ok. But if your bash is bad, now it's a race to patch properly before someone else gets it.
dorfsmay 12y ago
> If the above command outputs the current date (it may also show errors), you are still vulnerable. Well, it does, and no amount of apt-get update / install bash is fixing it. Is there a fix for this new issue? Do we know when it's going to be available in the big distros?
- dorfsmay 12y ago
  Also, does Apple intend to release a fix for OS X?
  - bennyg 12y ago
    I think you should use homebrew to get an update. Apple hasn't updated bash since like 2007.
  - saidajigumi 12y ago
    Yes: http://www.imore.com/apple-working-quickly-protect-os-x-against-shellshock-exploit http://www.imore.com/apple-working-quickly-protect-os-x-agai... They're working on getting a patch out. I'm disappointed with how Apple downplays the risk in their public statement. Some of the vectors for vulnerability are pretty insidious (e.g. the DHCP client vuln). Worth noting, it appears that OS X DHCP is not vulnerable to shellshock[1]. [1] http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-you/ http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-d...
shellshocker 12y ago
Now taking pull requests @ https://github.com/wreiske/shellshocker https://github.com/wreiske/shellshocker
err4nt 12y ago
I wouldn't trust this tool, at least not yet. I tried a knowned patched server and it gave me an unknown result. Next I tried a known vulnerable server I don't have the authority to patch, and it said it timed out because my server didn't respond within 3 seconds. Then it told me I had to wait 15 minutes to test that domain again. 0/2 when starting with known results, I wouldn't rely on this for anything you don't already know the status of.
- shellshockernet 12y ago
  Can you submit an issue request to https://github.com/wreiske/shellshocker/issues https://github.com/wreiske/shellshocker/issues and please provide the domain name used in the test. Thanks!

82 points by ericclemmons 12y ago

There have been a lot of articles about ShellShock, but this site is the most straightforward I've found for developers (not familiar with Bash, security, etc.) to test & fix Bash.

knave 12y ago

Particularly useful is the patch from source. I've already used it for an Ubuntu 11.04 server (past end of life for apt support), and am about to start on some RHEL servers

ck2 12y ago

Just a caution that newegg has a registered trademark on "shell shocker" - not sure if that is a problem or not.

chrisan 12y ago
Given Newegg's fights on patent trolls and that shellshocker.net is about helping people secure themselves vs selling electronics... I would think they are safe from litigation /ianal edit: Maybe Mattel will however :) http://trademarks.justia.com/857/91/shell-shocker-85791354.html http://trademarks.justia.com/857/91/shell-shocker-85791354.h...
- brador 12y ago
  It's still a trademark and if they want to keep it they have to show they're willing to protect it, else they could lose it.
  - itsame 12y ago
    Not a lawyer, but as I understand it, trademarks often cover only specific market categories. That is, someone can in some cases use a trademark in a market category that the original trademark owner does not operate (e.g. Company1 using BrandA sells only consumer electronics, some Company2 can actually later use BrandA to sell baby diapers). As long as BrandA isn't sufficiently famous and there is no risk of confusion or brand dilution, then Company2 isn't necessarily going to get in trouble. Of course, determining where the line gets drawn probably isn't always a matter of checking off items in some checklist (gray areas, etc.). Nevertheless, in the case of Newegg's Shell Shocker deals, it doesn't seem to me like it overlaps with this site's intent (vulnerability testing). Only overlap I see is that it's something that's operated over the Internet. Would be far-fetched to say that this site is capitalizing on Newegg's brand goodwill to... get people to test for server/machine vulnerabilities. Also... "It is not necessary for a trademark owner to take enforcement action against all infringement if it can be shown that the owner perceived the infringement to be minor and inconsequential. This is designed to prevent owners from continually being tied up in litigation for fear of cancellation."[1] So just because Newegg has a trademark doesn't mean it immediately and invariably has an obligation to enforce it at the threat of losing it. [1] http://en.wikipedia.org/wiki/Trademark#Maintaining_rights http://en.wikipedia.org/wiki/Trademark#Maintaining_rights
    - lutusp 12y ago
      > Not a lawyer, but as I understand it, trademarks often cover only specific market categories. That is, someone can in some cases use a trademark in a market category that the original trademark owner does not operate (e.g. Company1 using BrandA sells only consumer electronics, some Company2 can actually later use BrandA to sell baby diapers). As long as BrandA isn't sufficiently famous and there is no risk of confusion or brand dilution, then Company2 isn't necessarily going to get in trouble. This is true, and when a trademark holder attempts a legal action, they have to show a possibility for public confusion and loss of business to the "infringer". This is why Apple Music (the Beatles) and Apple Computer were free to coexist for decades -- no prospect for public confusion. By contrast, there's a now-famous case in which someone whose name was McDonald, and who operated a restaurant named "McDonald's", was obliged to rename his establishment after the other, much bigger McDonald's brought legal action on the ground of public confusion. The fact that the man's name was McDonald wasn't sufficient grounds to justify the name. I had a legal tangle which this protected-word issue. I once had a Web page that provided sunrise and sunset times. I foolishly called it "Sun computer". The other Sun Computer quickly threatened legal action for my use of the protected word "sun". No, boys and girls, I'm not making this up: http://www.arachnoid.com/lutusp/sunrise/#The__Sun_Computer__Story http://www.arachnoid.com/lutusp/sunrise/#The__Sun_Computer__...

claudius 12y ago

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. Furthermore, keep in mind http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste and use C-x C-e.

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.

ck2 12y ago

This post claims that it is still not fixed and there is a 3rd case: http://seclists.org/oss-sec/2014/q3/741 http://seclists.org/oss-sec/2014/q3/741 http://seclists.org/oss-sec/2014/q3/711 http://seclists.org/oss-sec/2014/q3/711 Was that before the second patch was sent out last night? Or can we expect a third patch this weekend?

tokenizerrr 12y ago
The posts you linked are just referring to the actual "feature", not another exploit. This feature is being able to define functions from enviroment variables, and requires the attacker to be able to control both the enviroment variable name & value. If an attack can do this, they can also set LD_PRELOAD and a whole host of other nasty enviroment variables.

chrisan 12y ago

So if you don't run CGI nor run a system command within your code, are you fairly safe? If you do have some gem that runs a system cmd, wouldn't it still require url input to get passed down to that command? I'm not advocating NOT upgrading your systems, but still fuzzy on the attack vector if this test requires I upload a cgi script

schwag09 12y ago
No, DHCP has been proven vulnerable on some systems. So, a system can be exploited by this bug just by connecting to a LAN (e.g. wifi network). Any protocol or service that runs via BASH is vulnerable. CGI is currently the largest and easiest attack vector to test for.
- brador 12y ago
  So assuming it's an online EC2 server LAMP stack with an empty cgi folder and a lone html page with hello world. Is that vulnerable to this exploit?
  - tych0 12y ago
    Yes.
    - hnha 12y ago
      remotely? how?

korzun 12y ago

> Possibly vulnerable. This could mean that the server is not at all vulnerable, or we just couldn't detect it as being vulnerable. They should just leave the last part "We couldn't detect it as being vulnerable."

shellshocker 12y ago

I'm taking all of your comments into consideration. I've made two updates already: Removed "This could mean that the server is not at all vulnerable" from the warning messages. Fixed the second exploit to be bash, not sh.

PabloFanque 12y ago
Your site currently (2pm EST) lists two exploits, but omits a third variant which "Mitchell" posted in your site's comments 8 hours ago. I've tested two fully updated Ubuntu servers. Both are not vulnerable to the two exploits you posted, but both are vulnerable to the exploit listed in Mitchell's comment. I suggest you post Mitchell's variant prominently as well. The two exploits you've posted: 1. env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 2. env X='() { (a)=>\' bash -c "echo date"; cat echo The third variant Mitchell posted in his comment: 3. env -i X=' () { }; echo hello' bash -c 'date' The systems I've tried these on both have been updated with "sudo apt-get update"; "sudo apt-get dist-upgrade". The systems are: A. Ubuntu 12.04.5 LTS, running Bash version 4.2.25(1)-release (x86_64-pc-linux-gnu) B. Ubuntu 10.04.4 LTS, running version 4.1.5(1)-release (x86_64-pc-linux-gnu)
- plorg 12y ago
  My updated 14.04 (bash version 4.3.11(1)-release) doesn't appear to be vulnerable to this third exploit.

kazinator 12y ago

I suspect is no need for the "env" command in these examples. That is to say, rather than env X='() { (a)=>\' bash -c "echo date"; cat echo just X='() { (a)=>\' bash -c "echo date"; cat echo That is to say, the shell already has the "env" functionality built in: VAR1=value1 VAR2=value2 ... VARN=valuen command arg ...

spydum 12y ago

When building bash (at least for some variants of Fedora), don't you need to specify the prefix as / so that it copies to /bin? Otherwise, I think it's just installed to $ac_default_prefix/bin, which is usually /usr/local/bin, leaving your old vulnerable one still in /bin/bash ./configure --prefix=/

shellshocker 12y ago
Updated! Thanks for that.

tpfister 12y ago

This patch script doesn't seem to fix CVE-2014-7169 (the second exploit) on some distributions. I have confirmed that the vulnerability still works after patching with Debian etch and lenny installations. I have issued an updated patcher script that fixes the patch: https://github.com/tpfister/public/blob/master/patch_shellshock_and_aftershock.sh https://github.com/tpfister/public/blob/master/patch_shellsh... The relevant changes are: # aftershock patch CVE-2014-7169 wget -nv http://tomas.pfister.fi/aftershock_4.3.txt http://tomas.pfister.fi/aftershock_4.3.txt patch -p0 < aftershock_4.3.txt After patching the second vulnerability no longer works: tp@tp:~/src/bash-4.3$ env X='() { (a)=>\' ./bash -c "echo date"; cat echo ./bash: X: line 1: syntax error near unexpected token `=' ./bash: X: line 1: `' ./bash: error importing function definition for `X' date cat: echo: No such file or directory tp@tp:~/src/bash-4.3$

shellshocker 12y ago
This is an older, more vulnerable version of BASH. Our script provides 4.3 with fixes, not 3.2
- tpfister 12y ago
  The script has been updated to bash 4.3.

roozbeh18 12y ago

not sure what this means "hmm... (HTTP/1.1 200 OK): Possibly vulnerable. We couldn't detect it as being vulnerable. We are working on an update to this scanner that will allow for a deeper scan."

shellshocker 12y ago
That means that the server could of been vulnerable, but it didn't return that it was.

nounaut 12y ago

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

rasur 12y ago

When the system you're testing replies with a '400 Bad request' (as mine do ;) ), you're probably in "safe" territory, no?

shellshocker 12y ago
I would say so yes. Have you tried the exploit cgi listed on the website to test?
- rasur 12y ago
  I'll have to set something up that actually uses cgi-bin. However, my load-balancer would still kill the request, I suspect. (EDIT: Sorry.. my point being; your site should probably class 400's as 'safe'?)

deleted 12y ago

[deleted]

wiredfool 12y ago

So, to test, they want their CGI put where it will execute in the webroot. And, if you didn't have cgis that were vulnerable before, now anyone can root your machine. So, if your bash is ok, you're ok. But if your bash is bad, now it's a race to patch properly before someone else gets it.

dorfsmay 12y ago

> If the above command outputs the current date (it may also show errors), you are still vulnerable. Well, it does, and no amount of apt-get update / install bash is fixing it. Is there a fix for this new issue? Do we know when it's going to be available in the big distros?

dorfsmay 12y ago
Also, does Apple intend to release a fix for OS X?
- bennyg 12y ago
  I think you should use homebrew to get an update. Apple hasn't updated bash since like 2007.
- saidajigumi 12y ago
  Yes: http://www.imore.com/apple-working-quickly-protect-os-x-against-shellshock-exploit http://www.imore.com/apple-working-quickly-protect-os-x-agai... They're working on getting a patch out. I'm disappointed with how Apple downplays the risk in their public statement. Some of the vectors for vulnerability are pretty insidious (e.g. the DHCP client vuln). Worth noting, it appears that OS X DHCP is not vulnerable to shellshock[1]. [1] http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-you/ http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-d...

shellshocker 12y ago

Now taking pull requests @ https://github.com/wreiske/shellshocker https://github.com/wreiske/shellshocker

err4nt 12y ago

I wouldn't trust this tool, at least not yet. I tried a knowned patched server and it gave me an unknown result. Next I tried a known vulnerable server I don't have the authority to patch, and it said it timed out because my server didn't respond within 3 seconds. Then it told me I had to wait 15 minutes to test that domain again. 0/2 when starting with known results, I wouldn't rely on this for anything you don't already know the status of.

shellshockernet 12y ago
Can you submit an issue request to https://github.com/wreiske/shellshocker/issues https://github.com/wreiske/shellshocker/issues and please provide the domain name used in the test. Thanks!