Advisory 01/2006: PHP ext/session HTTP Response Splitting Vulnerability

2006-01-1300:00:00

vulners.com

JSON

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                    Hardened-PHP Project
                    www.hardened-php.net

                  -= Security  Advisory =-


 Advisory: PHP ext/session HTTP Response Splitting Vulnerability

Release Date: 2006/01/12
Last Modified: 2006/01/12
Author: Stefan Esser [[email protected]]

Application: PHP5 <= 5.1.1
Not Affected: PHP4
PHP5 with Hardening-Patch
Severity: PHP applications using PHP5's session extension are
vulnerable to HTTP Response Splitting attacks
Risk: Critical
Vendor Status: Vendor has released a bugfixed version
References: http://www.hardened-php.net/advisory_012006.112.html

Overview:

PHP is a widely-used general-purpose scripting language that is
especially suited for Web development and can be embedded into HTML.

During the development of the Hardening-Patch which adds security
hardening features to the PHP codebase, several vulnerabilities
within PHP were discovered. This advisory describes one of these
flaws concerning a weakness in the session extension.

Since PHP5 a user supplied session ID is sent back to the user within
a Set-Cookie HTTP header. Because there were no checks performed on
the validity of this session id, it was possible to inject arbitrary
HTTP headers into the response body of applications using PHP's
builtin session functionality by supplying a special crafted session
id.

This can be used to perform HTTP Response Splitting and Cross Site
Scripting (XSS) attacks on all applications using the session
extension.

Details:

PHP's own session functionality is using a so-called permissive
system to accept any kind of user supplied session ID. While this is
often criticized as the cause of easier session fixation attacks
against PHP applications, it also means that the session ID has to be
considered as user input in PHP applications.

Therefore it is up to the PHP application to decide if it accepts
the supplied session ID or rejects it because of f.e. not accepted
characters.

Until PHP5 the built-in session extension assumes that a user
supplied session ID is already known on the client side and therefore
it is not sent back to the client within a cookie. This behaviour
has changed in PHP5 and because there was no additional checks
added, this enables an attacker to inject anything he wants into the
Set-Cookie HTTP header. This obviously leads to HTTP Response
Splitting vulnerabilities in all applications using PHP's built-in
session handling.

By simply terminating the HTTP headers from within the Set-Cookie
HTTP header it is of course possible to inject part of the request
body and perform all kinds of Cross Site Scripting (XSS) attacks.

Because PHP's default session storage module, files, will issue a PHP
warning that a session ID with illegal characters was used, this is
not exploitable in some situations where output buffering is switched
off (on server and in the application), the files module is used and
PHP is configured to display warnings.

This means the recommended settings for PHP webservers are vulnerable
and because at least one of the conditions above are not met on nearly
all production servers, most PHP servers are vulnerable to this.

PHP servers using our Hardening-Patch are not vulnerable to this
because they ship with a HTTP Response Splitting protection enabled
by default and also use a strict session ID mode, which disallows all
session IDs not created by PHP itself.

Proof of Concept:

The Hardened-PHP project is not going to release exploits for this
vulnerability to the public.

Recommendation:

It is strongly recommended to upgrade to the latest appropriate PHP
release as soon as possible. On the one hand there are also other
fixes in it and on the other hand it finally comes with a HTTP
Response Splitting protection.

Additionally we always recommend to run PHP with the Hardening-Patch
applied, because this vulnerability once again proved that our users
are protected against unknown vulnerabilities before they become
public knowledge.

GPG-Key:

http://www.hardened-php.net/hardened-php-signature-key.asc

pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDxpDDRDkUzAqGSqERAoqyAJ4gFYE2bPVC1N4AAhidWFk2460gsACgmY2d
qK3r8cAsVboCg0ca+cMqS1w=
=HGR8
-----END PGP SIGNATURE-----

JSON