[Reiko]

tl;dr everyone has aids

Yesterday, a serious bug affecting all versions of GNU bash was disclosed. The bug is in parsing of functions inside environment variables. Specifically, bash does not stop parsing functions at the end of the function. It will continue to execute whatever code it was given. This is remotely exploitable through any condition that allows a user to set environment variables and run bash.

An example would be HTTP headers being sent before running a CGI script. Web servers pass these headers through environment variables, therefore nearly all Linux systems running CGI on webservers are vulnerable at this moment.

The simplest way of getting execution through this bug is to send a malformed bash function as your user agent, like this one:

PHP Code:

() { :;}; YOUR COMMANDS HERE

Here is a local way to check if you are vulnerable.

PHP Code:

env "x=() { :;}; echo vuln;" bash

There is only a partial patch available at the time of this writing. To fully work around this bug for now, you'll have to set a Bourne-compatible shell as your system shell, like so:

PHP Code:

cd /bin; rm sh; ln -s dash sh # DO NOT DO THIS WITHOUT DASH INSTALLED. YOU WILL MESS UP YOUR SYSTEM.

EDIT: Just making it clear that HTTP is not the only way to exploit this. If you are running bash on or before September 25th, 2014, you are exploitable somehow. Period. DHCP clients are affected, webservers are affected, anything that calls system() is affected, your cron scripts are potentially affected, your init scripts are potentially affected and SSHd is affected, allowing for bypass of ForceCommand directives. Even your Macbook is vulnerable. This is serious shit.

[roger_smith]

great post as usual. I know we've been taking measures since this was announced

[Reiko]

Thanks Roger. I had a nice all-night run "patching" this (setting dash as system shell and running intrusion checks) on about 50 machines >.>

[Adorapuff]

Thanks Roger. I had a nice all-night run "patching" this (setting dash as system shell and running intrusion checks) on about 50 machines >.>

That's a shit ton of machines. I saw a writeup of this vuln yesterday, and my jaw dropped.

Here's one of the first exploits in the wild: https://gist.github.com/anonymous/929d622f3b36b00c0be1
I'm on OSX, and Rieko's test code didn't work on me, but this one did

Code:

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

Remember, any patch you guys put on right now, isn't a full patch and as Rieko said, a partial patch meaning that there is still a chance of exploitation.

3 Public sploits from exploit-db:
http://www.exploit-db.com/exploits/34777/
http://www.exploit-db.com/exploits/34765/
http://www.exploit-db.com/exploits/34766/

[Reiko]

Even setting dash as system shell doesn't 100% fix this. It just greatly limits your exposure. If you have CGI scripts that actually depend on bash, and specifically depend on bash, you're still hosed.

For routers, at least routers running DD-WRT, it can be worked around by forcing authentication on all pages. The HTTP daemon asks for auth before it ever serves or executes a CGI page. This doesn't mean that an evil or compromised ISP can't still pwn you via DHCP though.

In case you haven't noticed yet, this one's really, really bad.

[roger_smith]

Even setting dash as system shell doesn't 100% fix this. It just greatly limits your exposure. If you have CGI scripts that actually depend on bash, and specifically depend on bash, you're still hosed.

For routers, at least routers running DD-WRT, it can be worked around by forcing authentication on all pages. The HTTP daemon asks for auth before it ever serves or executes a CGI page. This doesn't mean that an evil or compromised ISP can't still pwn you via DHCP though.

In case you haven't noticed yet, this one's really, really bad.

Darn, and I decided to take this week off for vacation :p

[Reiko]

Darn, and I decided to take this week off for vacation :p

You picked a good week for it. Yesterday when I was notified of this via SMS by a friend, my response was "DONT CARE SLEEPING ALSO GRSEC AND MOD_SECURITY" just like that, in all caps. After I woke up I read it again and freaked out.

[Eclipse]

Wow, this is pretty big. Lucky for me I don't have any servers right now. I'll just sit here with popcorn and watch the drama unfold.

[Adorapuff]

Even setting dash as system shell doesn't 100% fix this. It just greatly limits your exposure. If you have CGI scripts that actually depend on bash, and specifically depend on bash, you're still hosed.

For routers, at least routers running DD-WRT, it can be worked around by forcing authentication on all pages. The HTTP daemon asks for auth before it ever serves or executes a CGI page. This doesn't mean that an evil or compromised ISP can't still pwn you via DHCP though.

In case you haven't noticed yet, this one's really, really bad.

Do you mean router or modem? Because my router connects to my modem which connects to the ISP from what I understand. DD-WRT is only accessible from my local net as I it is running on a router.

[Reiko]

Wow, this is pretty big. Lucky for me I don't have any servers right now. I'll just sit here with popcorn and watch the drama unfold.

You have a router in your house. If it's not a cheap piece of trash VxWorks router, you're vulnerable too.