Even More Evidence Of Php Becoming The New C

Another example of how PHP can be dangerous. Having to know the internal workings of variable acceptance to implement secure data checking seems to negate the value of having a higher-order programming language.

And, it is common in other languages to work with variables in a REQUEST structure of some sort.

PHP should provide a built-in set of semantics for data input filtering that work across all of the possible input types so that each application doesn’t have to build their own. I even remember when you used to have to build your own PHP session management or use additional PHP modules (PHPlib was a great implementation) before it got rolled into PHP 4.

Also check out the Hardened-PHP Project for this advisory and many others for PHP applications, and some PHP security basics talks.

-J

-----Original Message-----
From: Stefan Esser [mailto:sesser@hardened-php.net]
Sent: Saturday, July 02, 2005 12:09 AM
To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: Advisory 03/2005: Cacti Multiple SQL Injection Vulnerabilities [FIXED]

-----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: https://www.hardened-php.net/advisory-032005.php

Overview:

Quote from https://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

https://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:

https://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.