

Security Advisory: Phusion Passenger and the CVE-2014-6271 Bash Vulnerability - gdeglin
http://blog.phusion.nl/2014/09/25/security-advisory-phusion-passenger-cve-2014-6271-bash-vulnerability/

======
WestCoastJustin
Patch is out for CVE-2014-7169 on debian @ [https://lists.debian.org/debian-
security-announce/2014/msg00...](https://lists.debian.org/debian-security-
announce/2014/msg00223.html)

~~~
sandstrom
It tricked down to Ubuntu just now:
[http://www.ubuntu.com/usn/usn-2363-1/](http://www.ubuntu.com/usn/usn-2363-1/)

------
molf
How is Passenger affected? If there is an attack vector using Passenger I'm
going to be even more worried than I already was.

~~~
FooBarWidget
Phusion Passenger author here. See
[https://github.com/phusion/passenger/issues/1286](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.

~~~
molf
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.

~~~
FooBarWidget
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.

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

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

~~~
FooBarWidget
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?

~~~
molf
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!

~~~
FooBarWidget
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.

