Date: Sat Jul  2 08:12:12 2005
From: sesser at hardened-php.net (Stefan Esser)
Subject: Advisory 04/2005: Cacti Remote Command Execution
	Vulnerability

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


                       Hardened - PHP Project
                        www.hardened-php.net

                      -= Security  Advisory =-



     Advisory: Cacti Remote Command Execution Vulnerability
 Release Date: 2005/07/01
Last Modified: 2005/07/01
       Author: Stefan Esser [sesser@...dened-php.net]

  Application: Cacti <= 0.8.6e
     Severity: Wrongly implemented user input filters allows
               injection of user input into executed commandline
         Risk: Critical
Vendor Status: Vendor has released an updated version
   References: http://www.hardened-php.net/advisory-042005.php


Overview:

   Quote from http://www.cacti.net
   "Cacti is a complete network graphing solution designed to harness 
   the power of RRDTool's data storage and graphing functionality. 
   Cacti provides a fast poller, advanced graph templating, multiple 
   data acquisition methods, and user management features out of the 
   box. All of this is wrapped in an intuitive, easy to use interface 
   that makes sense for LAN-sized installations up to complex 
   networks with hundreds of devices."

   Alberto Trivero posted his Remote Command Execution Exploit for
   Cacti <= 0.8.6d to Bugtraq on the 22th June. Having analysed his
   bug we come to the conclusion, that the malfunctioning input
   filters, which were already mentioned in the previous advisory
   are also responsible for this bug still being exploitable.


Details:

   With the recent release of Cacti 0.8.6e a number of user input
   filters were added to the codebase to prevent a number of 
   SQL Injection problems. 
   
   However these user input filters that made Alberto Trivero 
   believe, that his remote command execution vulnerability was 
   also fixed, are wrongly implemented and therefore can be 
   bypassed to execute arbitrary commands on the webserver.
   
   To demonstrate the problem here a snipset of "graph_image.php"
   
   /* ================= input validation ================= */
   input_validate_input_number(get_request_var("graph_start"));
   input_validate_input_number(get_request_var("graph_end"));
   input_validate_input_number(get_request_var("graph_height"));
   input_validate_input_number(get_request_var("graph_width"));
   input_validate_input_number(get_request_var("local_graph_id"));
   input_validate_input_number(get_request_var("rra_id"));
   /* ==================================================== */
   
   ...
   
   /* override: graph start time (unix time) */
   if (!empty($_GET["graph_start"])) {
     $graph_data_array["graph_start"] = $_GET["graph_start"];
   }

   ...
   
   print rrdtool_function_graph($_GET["local_graph_id"], 
                             $_GET["rra_id"], $graph_data_array);    
   
   On the first look this code looks like it has fixed the remote
   command execution vulnerability through the 'graph_*' request
   parameters, because it requires them to be a number before
   passing them to the rrdtool.

   To realize that this check is however worth nothing one has to
   dig deeper and look into the implementation of get_request_var()
   
   function get_request_var($name, $default = "")
   {
     if (isset($_REQUEST[$name]))
     {
       return $_REQUEST[$name];
     } else
     {
       return $default;
     }
   }
   
   This actually means that the filter in this example is applied to
   the content of $_REQUEST["graph_start"] instead of 
   $_GET["graph_start"]. The problem with this is, that $_REQUEST is 
   a merged version of the $_GET, $_POST and $_COOKIE arrays and 
   therefore array keys of the same name will overwrite each other 
   in $_REQUEST.
   
   In the default configuration of PHP which is usually not changed
   by anyone the merge order is GPC. This means when the request
   contains both $_GET["graph_start"] and $_POST["graph_start"], only
   the posted value will end up in the $_REQUEST array.
   
   This however means, that an attacker can still inject shell 
   commands by supplying the injection string through the URL and
   supplying a good string through POST or through the COOKIE.


Proof of Concept:

   The Hardened-PHP Project is not going to release exploits 
   for this vulnerabilities to the public.


Disclosure Timeline:

   25. June 2005 - Contacted Cacti developers via email
   29. June 2005 - Review of patch from our side
    1. July 2005 - Release of updated Cacti and Public Disclosure


Recommendation:

   We strongly recommend upgrading to Cacti 0.8.6f which you can get at

	http://www.cacti.net/download_cacti.php


Summary for Secunia:

   Because Secunia proofed several times in the past, that they have
   enormous problems with reading advisories and crediting the right 
   parties in their advísory rip-offs, here a short summary.
   
   The bug described in this advisory is an input filtering malfunction.
   This is related to, but not exactly the bug Alberto Trivero found,
   because when he audited Cacti there was no input filtering at all.
   

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


Copyright 2005 Stefan Esser. All rights reserved.

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

iD8DBQFCxBcLRDkUzAqGSqERAgMuAKDkWDhBE2cpSfcaZ6K81IDmmZfqaACfcx6f
2ay9a8FMtLTkL0743yiMIrI=
=C4+c
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists