Hacker News new | comments | show | ask | jobs | submit login

Phusion Passenger author here. See https://github.com/phusion/passenger/issues/1286 for details.

In short: Phusion Passenger sometimes spawns application processes (e.g. during startup). This spawning happens through bash. Some environment variables are set according to certain HTTP headers' values.

We've been hoping the entire day that bash is going to be fixed "any time now", but the fix still isn't released. If it's still vulnerable by tomorrow we'll release a temporary workaround that fixes it inside Phusion Passenger, by not setting those environment variables. However this workaround will break apps that relied on it.

Furthermore, this workaround will have no effect on any other software which may be vulnerable. The core problem is bash. Until bash is fixed, there's no way to get rid of this vulnerability completely.

Please note that Shellshock+Phusion Passenger does not grant you root access. Phusion Passenger lowers privilege before calling bash.

In the mean time, you can lower your risk by configuring a static process pool (passenger_min_instances N, passenger_max_pool_size N). That way you will reduce process spawning in Phusion Passenger to a minimum.

[EDIT] Looks like the bash patch is released in Debian 7. Other OSes may soon follow.

Ah yes, I see now. Environment variables are set based on the request. They seem similar to CGI – we're in trouble.

Is this necessary for any processing by Passenger or the web application, or is just for legacy compatibility? Can the env vars be disabled if they're otherwise unused?

Edit: I agree with everything you said. If the env vars aren't strictly necessary for most apps I would deeply appreciate a patch that disables them completely. This would be good to have, even if bash is fixed – because I don't trust it anymore to handle env vars properly after having seen some of the parsing issues.

We don't set environment variables/call bash on every request. Only during process spawning. If you configure a static process pool so that no new process spawning occurs, you should be 99% safe.

In Phusion Passenger 5 we're not going to set any environment variables based on request data.

Still, at the end of the day, environment variables are supposed to be safe. Trying to patch software to not set environment variables, or trying to patch them to not use bash, borders insanity. There's only one right place to fix this, and that's in bash.

> We don't set environment variables on every request.

Are you sure? That's not what I'm seeing.

Yes. I wrote that code personally. Besides, setting environment variables on every request is not thread-safe and kills performance, so we explicit chose not to do that.

What behavior are you seeing that implies otherwise?

QUERY_STRING, REQUEST_URI and others are set according to the HTTP request in my environment. Could be Rack/Rails – I haven't checked yet.

Edit: Oh, I see now – you're right: they don't actually change on each request. Tested with %x{env > /tmp/env}.

Thanks for your clarifications!

Those are not system environment variables (which is what is used to exploit bash). Those are Rack environment variables, which are stored in an entirely different manner, and have no effect on bash.

We do set system environment variables for REQUEST_URI, QUERY_STRING, etc, but only during process spawning. Which is why I suggested configuring a static process pool.

In Phusion Passenger 5, we will no longer set system environment variables for REQUEST_URI, QUERY_STRING, etc because of a major architectural overhaul. This also accidentally happens to work around Shellshock.

Will the following settings ensure a 'static process pool'?

    passenger_min_instances 2;
    passenger_max_pool_size 2;



If PassengerLoadShellEnvvars is set to 'no' or the login shell is not bash (or sh) would this analysis apply? The documentation and code seem to say that bash would not be used for spawning in these two configurations.

There is no link given to the Debian 7 patch for CVE-2014-7169, is there actually such a thing?

Indeed. When PassengerLoadShellEnvvars is turned off, or if bash is not the user's configured shell, it will not invoke bash.

Regarding the Debian 7 patch: I can't find the link, but they released bash package 4.2+dfsg-0.1+deb7u3 shortly before we published the advisory. The changelog explicitly mentions CVE-2014-7169. I also tested the exploit code, and wasn't able to trigger the exploit on their new bash.

It looks like something happened overnight last night and the patch became visible after I posted.

You may want to update the docs to include zsh and ksh as shells that you will use since shouldLoadShellEnvvars checks for all three.

I found a place where back ticks are used to get something done: file lib/phusion_passenger/platform_info/apache.rb, method httpd_infer_envvar. If Passenger somehow gets a corrupted environment and calls httpd_infer_envvar then it would trip over Shellshock on an unpatched system. I didn't search generally for back ticks or other shell entry points, but you may want to remove extraneous shell invocations as a future proofing step against other vulnerabilities showing up in shells. (I know, you said that was insane, but so was all of yesterday :)

httpd_infer_envvar is never called from HTTP requests. It's only used by administrative command line tools.

Does this apply if PassengerLoadShellEnvvars is set to 'no' or if bash is not the login shell?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact