Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 7 Dec 2015 16:07:23 +0100
From: Andreas Stieger <astieger@...e.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2015-7519: Phusion Passenger Header overwriting issue


Header overwriting issue in Phusion Passenger
https://www.phusionpassenger.com/ - https://github.com/phusion/passenger
CRD was 2015-12-07 11:00 UTC / 12:00 CET.
Upstream developers were informed and agreed, and issued the text below and the attached patch. Fixed in release 5.0.22.
Discovered by Moises Deniz, Michael Schröder, Adrian Schröter of SUSE Linux.
SUSE bug: https://bugzilla.suse.com/show_bug.cgi?id=956281

https://github.com/phusion/passenger/commit/ddb8ecc4ebf260e4967f57f271d4f5761abeac3e

CVE-2015-7519 was assigned to this issue.

------------ issue -------------
1. Given the precondition that the SCGI protocol is used (in Passenger
this means Rack/Rails or Python), and an app depends on a header set by
a trusted server (here: Apache) that includes a dash, for example:
Foobar-User: user

2. It is possible for an untrusted remote client to set a "colliding"
header:
Foobar_User: impersonation

3. The colliding header appears different to the server (_ instead of -)
and is thus not overwritten but preserved.

4. Conversion of the headers for SCGI requires dropping the (_ -)
difference, which results in Passenger sending two headers with the same
key:
HTTP_FOOBAR_USER: user
HTTP_FOOBAR_USER: impersonation

The exploit is then that the value "impersonation" of the second
HTTP_FOOBAR_USER may overwrite the value of the first (if a hashmap is
used), making the application believe a different value was set by the
server.

Indeed, we can make request.headers["HTTP_FOOBAR_USER"] show
"impersonation" instead of "user", confirming the issue, which can have
security implications, e.g. if the header is used for authentication.

------------ affected use-cases -------------
As far as we can see, affected use-cases are:
- Passenger, with Apache (Nginx already filters) or standalone/builtin,
using a Ruby or Python app (Node.js/Meteor/io.js don't use SCGI),
whereby the app depends on a server-set variable containing one or more
dashes.

------------ resolution -------------
We propose a different patch; not in the apache module but at the point
where the SCGI conversion occurs. The main reason is that this covers
the second affected path: standalone mode using the 'builtin' engine.
See attached (N.B. the httpToEnv you patched is unreferenced code and
has now been cleaned up).

The patch has been committed to the (internal) cgi_header_collision
passenger branch and is pending merge to stable, to be included in the
upcoming 5.0.22 release (ASAP).

------------ side-effects -------------
Like the patch in the mod_cgi mailing list, this one still breaks
applications that depend on non-standard (e.g. underscored) client
headers. Similarly, the workaround is the same, rewrite the necessary
header(s):
SetEnvIfNoCase ^X.Underscored.Header $ ^(.*)$ fix_header=$1
RequestHeader set X-Underscored-Header %{fix_header}e env=fix_header



-- 
Andreas Stieger <astieger@...e.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)






[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ