bash... your head in (CVE-2014-6271 shellshock)

So Mr. Chazelas disclosed that bash vulnerability today... and I am sure that a lot of people got really upset with him! This vulnerability has existed in the past 22 years (since version 1.13) so here is another beautifully kept secret ruined!

But lets take things from the top. RedHat's advisory summed it up quite nicely:

"A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue."

So let the patches flow right? Wrong! And here comes CVE-2014-7169 which states:

CVE-2014-7169 bash: code execution via specially-crafted environment (Incomplete fix for CVE-2014-6271)

Defense: 
Do not despair, keep patching your systems and update the signatures on your IDS/IPS boxes as well as your Web-Application Firewalls. Further reading here.

A very nice snip from NCC-Group's advisory available here describes the possibly affected systems and applications:

• Web servers using CGI scripts that are written in bash
• Web servers using CGI scripts that are written in other languages that invoke certain function calls:
  • C-based scripts calling system() or popen()
  • Python-based scripts that call os.system() or os.popen()
  • PHP-based scripts that call system() or exec() (when run in CGI mode)
  • Perl-based scripts that invoke shell commands
• Restricted SSH shells using ForceCommand can be bypassed. Some git and subversion deployments use such restricted shells.
• If an attacker is in a position to forge DHCP responses, it can enable root-level code execution in DHCP clients
• Set-UID applications may allow local escalation to root
• CUPS-based printer daemons are likely to be affected
• Mac and Linux Desktops are affected, and are likely to allow privilege escalation to a root user

Keep in mind that all this is very quick and not very thoroughly tested... so when McAfee or TippingPoint/Fortigate or whoever comes back with a IDS/IPS signature, don't blindly set it to block and go for a beer.. set the thing to trace or log or notify (whatever each one of them calls it) and have a look at the traffic you are about to block before you block it. Signatures for Snort or Suricata available here.

The system check:

env X="() { :;} ; echo broken" /bin/sh -c "echo not-broken"
env X="() { :;} ; echo broken" `which bash` -c "echo not-broken"

Oh... and don't forget all those "other" devices that run bash in the background... like your F5 BIG-IP boxes for example :)


Offense:
In the other side of the camp Robert Graham has posted a very neat masscan configuration to scan 0.0.0.0/0 (go Graham!!). He also raised the very valid point that this vulnerability.. is actually worm-able (let the fun begin!)

Metasploit wouldn't be left out of the party though! in the latest update a lovely scanner was made available (auxiliary/scanner/http/apache_mod_cgi_bash_env)

A very nice demo of the vulnerability is available on reddit

UPDATE:
We can see a preliminary wormification of the bug here, complements of @yinettesys and @troyhunt
Another lovely php script for shellshock by cxsecurity
And a DHCP RCE PoC from Geoff Walton in trustedsec


Keep patching... keep hunting :)