GLPI version 0.83.9 suffers from a remote PHP code execution vulnerability in the unserialize() function.
382173b69e5b1dc2a471b37ca3ebd677f1742f77e6ce5504c3668e6680febce1
=======================================
Advisory title: unserialize vulnerability in GLPI 0.83.9
Product: GLPI 0.83.9
Discovered by: Xavier Mehrenberger <at> Cassidian CyberSecurity
Vulnerable version: 0.83.9
Tested: v0.83.9, 2013-06-21
Fixed in repository: 2013-06-23 commits 21169 to 21180
Category: Potential PHP code execution
Vulnerability type: [CWE-502] Deserialization of Untrusted Data
CVE IDs: none yet
By: Xavier Mehrenberger
Cassidian CyberSecurity
http://www.cassidiancybersecurity.com
=======================================
----- CVE-2013-XXXX Required configuration: No specific configuration required
Steps to reproduce:
* Issue a request to
glpi/front/ticket.form.php?id=1&_predefined_fields=XXXX,
* replacing XXX with a serialized PHP object
Vulnerable code sample:
--- file ticket.class.php, function showFormHelpdesk
if (isset($options['_predefined_fields'])) {
$options['_predefined_fields']
=
unserialize(rawurldecode(stripslashes($options['_predefined_fields'])));
---
When passing a non-existent empty serialized class (ex: class called "exploit" value "O%3A7%3A%22exploit%22%3A0%3A%7B%7D"), an error occurs, which is caught by the userErrorHandlerNormal function in toolbox.class.php.
When a PHP object gets unserialized, its __wakeup() function is executed. When this object gets destroyed, its __destruct() function is executed (since PHP5). No such object exists throughout the GLPI codebase. However, it might exist in a third-party library, as demonstrated by Stefan Esser [2].
More information about this vulnerability class can be found at [1].
The unsafe use of unserialize() has been fixed throughout the codebase in commits 21169 [3] to 21180.
References:
[1] https://www.owasp.org/index.php/PHP_Object_Injection
[2] http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf