
Shellshock BASH Vulnerability Tester - ericclemmons
https://shellshocker.net/
======
claudius
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.

~~~
Zikes
Pales in comparison to

    
    
        curl https://shellshocker.net/fixbash | sh

~~~
windsurfer
Are you vulnerable to giving attackers shell access on your computers? Pipe
this into your shell and find out!

~~~
RAB1138
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
Not only that, but it's going to ask for your sudo password too. No reason to
be leary of that ;-)

------
spydum
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
Updated! Thanks for that.

------
shellshocker
Now taking pull requests @
[https://github.com/wreiske/shellshocker](https://github.com/wreiske/shellshocker)

------
ck2
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
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.

------
tpfister
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_shellsh...](https://github.com/tpfister/public/blob/master/patch_shellshock_and_aftershock.sh)

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
This is an older, more vulnerable version of BASH. Our script provides 4.3
with fixes, not 3.2

~~~
tpfister
The script has been updated to bash 4.3.

------
err4nt
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
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!

------
kazinator
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 ...

------
chrisan
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
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
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
Yes.

~~~
hnha
remotely? how?

------
wiredfool
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
> 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
Also, does Apple intend to release a fix for OS X?

~~~
saidajigumi
Yes: [http://www.imore.com/apple-working-quickly-protect-os-x-
agai...](http://www.imore.com/apple-working-quickly-protect-os-x-against-
shellshock-exploit)

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-d...](http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-
you/)

------
shellshocker
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
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
My updated 14.04 (bash version 4.3.11(1)-release) doesn't appear to be
vulnerable to this third exploit.

------
korzun
> 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."

------
roozbeh18
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
That means that the server could of been vulnerable, but it didn't return that
it was.

------
ericclemmons
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
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

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

~~~
shellshocker
I would say so yes. Have you tried the exploit cgi listed on the website to
test?

~~~
rasur
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'?)

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

~~~
chrisan
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.h...](http://trademarks.justia.com/857/91/shell-
shocker-85791354.html)

~~~
brador
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
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
> 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__...](http://www.arachnoid.com/lutusp/sunrise/#The__Sun_Computer__Story)

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

