It was discovered by the SUSE security team that it was possible, in some cases, for clients to overwrite headers set by the server, resulting in a medium level security issue. CVE-2015-7519 has been assigned to this issue. See also the SUSE issue report.

Affected use-cases

Header overwriting may occur if all of the following conditions are met:

Apache integration mode, or standalone+builtin engine without a filtering proxy

integration mode, or engine without a filtering proxy Ruby or Python applications only (Passenger 5); or any application (Passenger 4)

The app depends on a request header containing a dash (-)

(-) The header is supposed to be trusted (set by the server)

The client correctly guesses the header name

The issue is that internally, Passenger 5 uses an SCGI-inspired format to pass headers to Ruby/Python applications, while Passenger 4 uses an SCGI-inspired format to pass headers to all applications. This implies a conversion to UPPER_CASE_WITH_UNDERSCORES whereby the difference between characters like "-" and "_" is lost. An example of an attack:

User Mallory guesses that internally, X-User is used as an authentication header

is used as an authentication header Mallory sends a request with X_User: Bob , X-Auth-Token: ValidMallory

, Apache sees a valid X-Auth-Token , adds authentication header X-User: Mallory , lets the request through

, adds authentication header , lets the request through Passenger converts X-User: Bob and X_User: Mallory to HTTP_X_USER: Bob , HTTP_X_USER: Mallory

and to , The headers collide and the application might see HTTP_X_USER: Bob and assume Bob was authenticated

Fixed in Passenger 5.0.22, 4.0.60

This vulnerability affects all Passenger versions prior to 4.0.60 and 5.0.22.

It has been fixed by filtering out client headers that do not consist of alphanumeric/dash characters (Nginx already did this, so Passenger+Nginx was not affected). If your application depends on headers that don't conform to this, you can add a workaround in Apache specifically for those to convert them to a dash-based format. For example:

# Workaround, for untrusted (client) headers only! SetEnvIfNoCase ^X_Nonconfirming_Client_Header $ ^(.*)$ fix_header=$1 RequestHeader set X-Nonconfirming-Client-Header %{fix_header}e env=fix_header

See the individual blog posts about the Passenger 5.0.22 and 4.0.60 releases for upgrade instructions and information about other changes.