Navixia finds critical vulnerabilities in GLPI

The following article describes in detail two critical vulnerabilities found on GLPI by the Navixia Research Team.

These vulnerabilities have been reported to the software publisher and are already fixed in the latest release (0.84.2). A CVE has been attached with the following reference: CVE-2013-5696.

These vulnerabilities appear to be present on GLPI from version 0.68, released in 2006. However, the present article expands on source code taken from version 0.84, released on 09.08.2013.

GLPI (Gestion Libre de Parc Informatique) is an Open-Source web application designed to manage IT infrastructure and distributed under the General Public Licence (GPL). Currently, it is estimated that 2’400 entities use GLPI with an average of 800 users per entity. This represents a total of about 1'900'000 users.

SQL injection

The file "install/install.php" can be executed even if the installation process has already been performed. After setting the language, it checks the existence of the variable $ _POST ['install']. It enters a switch case based on its value en then calls the corresponding function.

File "install/install.php"

if (!isset($_POST["install"])) {
    $_SESSION = array();
    if (file_exists(GLPI_CONFIG_DIR."/config_db.php")) {
        Html::redirect(GLPI_ROOT."/index.php");
        die();
    } else {
        header_html("Select your language");
        choose_language();
    }
} else {

switch ($_POST["install"]) {

This section is problematic as it is possible to call any stage of the installation even if the application is already installed.

If, for example, we call the stage 'Etape_4', which is actually the function 'step7', it is possible to perform a SQL injection from HTTP headers (by changing the value of the referrer).

File "install/install.php"

function step7() {
    global $LANG, $CFG_GLPI;
    require_once (GLPI_ROOT . "/inc/dbmysql.class.php");
    require_once (GLPI_CONFIG_DIR . "/config_db.php");
    $DB = new DB();
    $query = "UPDATE `glpi_configs`
    SET `url_base` = '".str_replace("/install/install.php", "", $_SERVER['HTTP_REFERER'])."'
    WHERE `id` = '1'";
    $DB->query($query);

We can exploit this vulnerability to either trigger an error or use it as a blind sql injection point.

PHP Code Execution

Based on the previous finding, we note that the 'update1' function (step 'update_1') is particularly interesting as it defines the connection parameters to the database used in create_conn_file function.

File "install/install.php"

function create_conn_file($host, $user, $password, $DBname) {
    global $CFG_GLPI;
    $DB_str = "<!--?php
 class DB extends DBmysql {

 var $dbhost = '". $host ."';

 var $dbuser = '". $user ."';

 var $dbpassword= '". rawurlencode($password) ."';

 var $dbdefault = '". $DBname ."';

 } 
?-->";
    $fp = fopen(GLPI_CONFIG_DIR . "/config_db.php",'wt');
    if ($fp) {
        $fw = fwrite($fp,$DB_str);
        fclose($fp);
        return true;
    }
        return false;
    }
    function update1($host, $user, $password, $DBname) {
        global $LANG;
        if (create_conn_file($host,$user,$password,$DBname) && !empty($DBname)) {
            $from_install = true;
            include(GLPI_ROOT ."/install/update.php");

The parameters passed to the function 'update1' (host, user, password and DBname) are variables controlled by the user in a POST request:

File "install/install.php"

case "update_1" :
    if (empty($_POST["databasename"])) {
        $_POST["databasename"] = "";
        }
    update1($_POST["db_host"], $_POST["db_user"], $_POST["db_pass"], $_POST["databasename"]);
    break;

As parameters are defined by the user, it is possible to redefine after the installation the username, password and database name used by the application. The exploitation of this vulnerability on a production system will end up in a denial of service as the connection parameters to the database are no longer valid. This could also be used to connect to another database on another host.

Much more critical, if magic_quotes are disabled (which is now a default parameter), an attacker can specify values to the server that will execute PHP code. He could for example get a shell which would end up in a full compromise of the machine. From there he could use it as pivot to reach the internal network.

A Metasploit module has been developed by Navixia. It tests the existence of this vulnerability and then exploits it. It will be published on this website soon.