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