3 ms·

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 spawn

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?
  - molf 12y ago
    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 12y ago
      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.

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?
- molf 12y ago
  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 12y ago
    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.