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 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 Mallory sends a request with X_User: Bob, X-Token: ValidMallory Apache sees a valid X-Auth-Token, adds authentication header X-User: Mallory, lets the request through Passenger converts X-User: Bob and X_User: Mallory to X_USER: Bob, X_USER: Mallory The headers collide and the application might see X_USER: Bob and assume Bob was authenticated Fixed in Passenger 5.0.22, 4.0.60
passenger 4.0.60 and 5.0.22 are now in the tree.
Please test and mark stable: =dev-ruby/daemon_controller-1.2.0-r1 =www-apache/passenger-4.0.60
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
Cleanup done.
Arches and Maintainer(s), Thank you for your work. GLSA Vote: No Thank you all. Closing as noglsa.
