PHP ext/session Session Cookie Parameter Injection Vulnerability

From:http://www.php-security.org/MOPB/PMOPB-46-2007.html

 

Summary

PHP's ext/session does not URL encode the session id before placing it into the session cookie. Therefore characters with special meaning, like semicolons can be used to inject further cookie attributes into the session cookie.

PHP 5.2.3 does not fix this vulnerability because the PHP developers tried to outsmart our recommendation how to fix the problem.

Affected versions

Affected are PHP4 <= 4.4.7 and PHP5 <= 5.2.3

Detailed information

When the session_start() function is called PHP' ext/session will issue a new session cookie under some circumstances. These circumstances are for example

- session id was embedded into PATH_INFO
- session id was regenerated
- session id was set with session_id()
- session_start() was called more than once

In 3 of the 4 mentioned cases the session id is completely user supplied.
Because the session id is placed into the cookie without any kind of encoding this allows the injection of arbitrary cookie attributes into the session cookie HTTP header. This vulnerability is actually the same as the ext/session HTTP response splitting vulnerability disclosed by us in 2006, with the exception that injected newline characters will be catched due to the HTTP response splitting protection that was introduced into PHP.

In PHP 5.2.3 another attempt was made to fix this old problem by not sending out a session cookie when the session id is embedded in PATH_INFO. However this only closes one of multiple paths.

Proof of concept, exploit or instructions to reproduce

A proof of concept is not really needed, because the vulnerability is trivial. Giving an URL like http://www.server.de/session.php it is possible to inject arbitrary cookie parameters like this. (This example works in PHP4 for all session modules and for PHP5 < 5.2.3 in all session modules except "files").

http://www.server.de/session.php/PHPSESSID=ID;INJECTED=ATTRIBUTE;/

Additionally to this example that works against the PHP core session management it is possible to launch this attack against applications that use the session_id() function.

<?php
   
From:http://www.php-security.org/MOPB/PMOPB-46-2007.html
 
Summary
PHP's ext/session does not URL encode the session id before placing it into the session cookie. Therefore characters with special meaning, like semicolons can be used to inject further cookie attributes into the session cookie.

PHP 5.2.3 does not fix this vulnerability because the PHP developers tried to outsmart our recommendation how to fix the problem.
Affected versions
Affected are PHP4 <= 4.4.7 and PHP5 <= 5.2.3
Detailed information
When the session_start() function is called PHP' ext/session will issue a new session cookie under some circumstances. These circumstances are for example

- session id was embedded into PATH_INFO
- session id was regenerated
- session id was set with session_id()
- session_start() was called more than once 

In 3 of the 4 mentioned cases the session id is completely user supplied.
Because the session id is placed into the cookie without any kind of encoding this allows the injection of arbitrary cookie attributes into the session cookie HTTP header. This vulnerability is actually the same as the ext/session HTTP response splitting vulnerability disclosed by us in 2006, with the exception that injected newline characters will be catched due to the HTTP response splitting protection that was introduced into PHP.

In PHP 5.2.3 another attempt was made to fix this old problem by not sending out a session cookie when the session id is embedded in PATH_INFO. However this only closes one of multiple paths. 
Proof of concept, exploit or instructions to reproduce
A proof of concept is not really needed, because the vulnerability is trivial. Giving an URL like http://www.server.de/session.php it is possible to inject arbitrary cookie parameters like this. (This example works in PHP4 for all session modules and for PHP5 < 5.2.3 in all session modules except "files"). 
http://www.server.de/session.php/PHPSESSID=ID;INJECTED=ATTRIBUTE;/

Additionally to this example that works against the PHP core session management it is possible to launch this attack against applications that use the session_id() function. 
___FCKpd___1
 
Notes
This vulnerability has been disclosed on the 14th May 2007 to the PHP developers. They were explicitly told that they SHOULD URL encode the session id before placing it into the cookie.

They have choosen another fix that has other positive side effects but does not fix this vulnerability. It only fixes one of the attack vectors.

This vulnerability is related to another vulnerability that was disclosed by us in 2006. This means the vulnerability is only still open because in 2006 only one possible attack vector was closed instead of fixing the actual encoding problem. History will repeat again and again until the PHP developers learn to fix things correctly instead of using one hack after another to only fix the symptoms.

And finally they did it again: Obviously "their fix" got lost in all the chaos and this vulnerability is not mentioned in the release announcement of PHP 5.2.3 at all.
 
GET_VARIABLE = "ID;INJECTED=ATTRIBUTE;";
session_id(
From:http://www.php-security.org/MOPB/PMOPB-46-2007.html
 
Summary
PHP's ext/session does not URL encode the session id before placing it into the session cookie. Therefore characters with special meaning, like semicolons can be used to inject further cookie attributes into the session cookie.

PHP 5.2.3 does not fix this vulnerability because the PHP developers tried to outsmart our recommendation how to fix the problem.
Affected versions
Affected are PHP4 <= 4.4.7 and PHP5 <= 5.2.3
Detailed information
When the session_start() function is called PHP' ext/session will issue a new session cookie under some circumstances. These circumstances are for example

- session id was embedded into PATH_INFO
- session id was regenerated
- session id was set with session_id()
- session_start() was called more than once 

In 3 of the 4 mentioned cases the session id is completely user supplied.
Because the session id is placed into the cookie without any kind of encoding this allows the injection of arbitrary cookie attributes into the session cookie HTTP header. This vulnerability is actually the same as the ext/session HTTP response splitting vulnerability disclosed by us in 2006, with the exception that injected newline characters will be catched due to the HTTP response splitting protection that was introduced into PHP.

In PHP 5.2.3 another attempt was made to fix this old problem by not sending out a session cookie when the session id is embedded in PATH_INFO. However this only closes one of multiple paths. 
Proof of concept, exploit or instructions to reproduce
A proof of concept is not really needed, because the vulnerability is trivial. Giving an URL like http://www.server.de/session.php it is possible to inject arbitrary cookie parameters like this. (This example works in PHP4 for all session modules and for PHP5 < 5.2.3 in all session modules except "files"). 
http://www.server.de/session.php/PHPSESSID=ID;INJECTED=ATTRIBUTE;/

Additionally to this example that works against the PHP core session management it is possible to launch this attack against applications that use the session_id() function. 
___FCKpd___1
 
Notes
This vulnerability has been disclosed on the 14th May 2007 to the PHP developers. They were explicitly told that they SHOULD URL encode the session id before placing it into the cookie.

They have choosen another fix that has other positive side effects but does not fix this vulnerability. It only fixes one of the attack vectors.

This vulnerability is related to another vulnerability that was disclosed by us in 2006. This means the vulnerability is only still open because in 2006 only one possible attack vector was closed instead of fixing the actual encoding problem. History will repeat again and again until the PHP developers learn to fix things correctly instead of using one hack after another to only fix the symptoms.

And finally they did it again: Obviously "their fix" got lost in all the chaos and this vulnerability is not mentioned in the release announcement of PHP 5.2.3 at all.
 
GET_VARIABLE);
session_start();
...
?>

 

Notes

This vulnerability has been disclosed on the 14th May 2007 to the PHP developers. They were explicitly told that they SHOULD URL encode the session id before placing it into the cookie.

They have choosen another fix that has other positive side effects but does not fix this vulnerability. It only fixes one of the attack vectors.

This vulnerability is related to another vulnerability that was disclosed by us in 2006. This means the vulnerability is only still open because in 2006 only one possible attack vector was closed instead of fixing the actual encoding problem. History will repeat again and again until the PHP developers learn to fix things correctly instead of using one hack after another to only fix the symptoms.

And finally they did it again: Obviously "their fix" got lost in all the chaos and this vulnerability is not mentioned in the release announcement of PHP 5.2.3 at all.