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


                       Hardened - PHP Project
                        www.hardened-php.net

                      -= Security  Advisory =-



     Advisory: Cacti Multiple SQL Injection Vulnerabilities
 Release Date: 2005/07/01
Last Modified: 2005/07/01
       Author: Stefan Esser [sesser@hardened-php.net]

  Application: Cacti <= 0.8.6e
     Severity: Wrongly implemented user input filters lead to
               multiple SQL Injection vulnerabilities which can
         lead f.e. to disclosure of the admin password hash
         Risk: Critical
Vendor Status: Vendor has released an updated version
   References: http://www.hardened-php.net/advisory-032005.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."

   Because it is usually fun to audit software which was previously
   audited by experts from iDEFENSE we scanned through their reported
   vulnerabilities and found that most are not properly fixed.


Details:

   With the recent release of iDEFENSE's Cacti advisories version
   0.8.6e of Cacti was released which according to iDEFENSE fixes
   all reported flaws. But this is not true.
   
   However the user input filters that were added to the Cacti
   codebase to address the possible SQL Injections are wrongly
   implemented and therefore can be tricked to let attackers
   through.
   
   To demonstrate the problem here a snipset of "graph.php"
   
   /* ================= input validation ================= */
   input_validate_input_regex(get_request_var("rra_id"), "^([0-9]+|all)$");
   input_validate_input_number(get_request_var("local_graph_id"));
   /* ==================================================== */
   
   if ($_GET["rra_id"] == "all") {
     $sql_where = " where id is not null";
   }else{
     $sql_where = " where id=" . $_GET["rra_id"];
   }
   
   On the first look this code looks safe, because it checks that
   the 'rra_id' request parameter is either a number or the string
   "all" before inserting it into a part of the SQL Query.

   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["rra_id"] and not to $_GET["rra_id"].
   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["rra_id"] and $_POST["rra_id"], only the 
   posted value will end up in the $_REQUEST array.
   
   This however means, that nearly all of the implemented filters can
   be bypassed by supplying the attack 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.
   
   This bug was not found by iDEFENSE. On the contrary it is a bug 
   in the input filters that were implemented because of iDEFENSE
   and where nodded through by them.
   

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

iD8DBQFCxBb2RDkUzAqGSqERAk8iAKC8ifl5vl+GtQSw17XyyyZGHb438QCfRJGG
RwZhc/qfTE7pP8sxvE8pL4U=
=qYP/
-----END PGP SIGNATURE-----