6 ms·

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

• gdeglin 12y ago
  This blog post seems to confirm that there is indeed an attack vector using Passenger.
• FooBarWidget 12y ago
  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 12y ago
    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 12y ago
      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.
      • sandstrom 12y ago
        Will the following settings ensure a 'static process pool'? passenger_min_instances 2; passenger_max_pool_size 2;
        • FooBarWidget 12y ago
          Yes.
          • sandstrom 12y ago
            Thanks!
      • molf 12y ago
        > We don't set environment variables on every request. Are you sure? That's not what I'm seeing.
        • FooBarWidget 12y ago
          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?
          • 12y ago
  • swelmer 12y ago
    Does this apply if PassengerLoadShellEnvvars is set to 'no' or if bash is not the login shell?
  • swelmer 12y ago
    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?
    • FooBarWidget 12y ago
      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.
      • swelmer 12y ago
        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 :)
        • FooBarWidget 12y ago
          httpd_infer_envvar is never called from HTTP requests. It's only used by administrative command line tools.