In our previous calendar posts, we covered specific security issues in popular open-source applications that were detected by our code analysis solution RIPS. Most of the released issues lead to remote command execution, the most critical security vulnerability in PHP applications. But are all findings always exploitable? For more diversity of our calendar, we would like to introduce a few interesting examples today that turned out to be not exploitable and how RIPS handles these scenarios.

Invalid Code

The following code was found in the XOOPS project. User input is saved in the variable $filter and then used in a call to eval() - a security nightmare.

image.php

301302303

$filter = isset($_GET['filter']) ? $_GET['filter'] : false;
$destination_image = imagecreatetruecolor($tn_width, $tn_height);
eval("imagefilter({$destination_image}, {$filter});");

The code does look vulnerable at first sight, doesn’t it? But in fact, it is not. The built-in PHP function imagecreatetruecolor() returns an image resource. This resource is type-casted to the string Resource id #x when concatenated in line 303 for evaluation. The resulting code eval("imagefilter(Resource id #4, {$filter});") is always invalid and, unfortunately, the syntax error appears before the injection point. Even though an attacker can inject arbitrary code into eval(), it will always throw a syntax error. It is confusing why the call to eval() was added that renders this line useless.

A code analyzer, dynamic or static, cannot reason if the evaluated code will fail with all possible inputs. Still, it is important to reveal this issue with an analysis report because a future code change can automatically lead to a remote code execution vulnerability.

Unreachable Code

Another very common source for non-exploitables is code that cannot be reached by a remote attacker. In our examinations of analysis results, we found many vulnerabilities in install scripts that are only used once by an administrator during setup and are then removed from the web server (ideally). The past has shown, though, that even vulnerabilities in an installer can be exploited. For example, a file delete vulnerability could allow to restore an install routine that is then abused by an attacker, as reported in the Gallery3 project.

Unit tests are another good example of code that is unreachable for an attacker. These are usually invoked from the command line and stored safely outside of the web root. As an example, we investigated a PHP object injection vulnerability in an unit test for Drupal just for fun.

The solution to avoid issue reports in install scripts or unit tests is simple. In RIPS, you can maintain a list of directories that should be excluded from your security analysis, as shown in our demo interface.

Dead Code

Further, we experience a lot of legacy code in PHP applications. It is not uncommon that functions or classes remain in the code base, even when they are not in use anymore. RIPS reports findings in this code regardless. For one, it is possible that a reflection injection vulnerability or an autoloader allows to reach the code in a way not intended. Second, even unused code should not contain security vulnerabilities because a developer might use it again in the future. Thus, it is crucial to be notified about ticking time bombs in your code.

If RIPS is not able to find the point of invocation for vulnerable code it will say so. It is up to the auditor to decide how to handle the issue. For example, eFront contains this dangerous function that could be used to execute arbitrary PHP code.

libraries/globals.php

643644645646

function handleSEO() {
    $parts = explode("/", trim($_SERVER['PATH_INFO'], "/"));
    for ($i = 0; $i < sizeof($parts); $i += 2) {
    eval('$' . $parts[$i] . ' = "' . $parts[$i + 1] . '";');

RIPS is not able to find a call to the function handleSEO(), because it is not used anymore. To communicate this, the code summary contains the following entry with a file name that is not available.

n/a

1

handleseo();

Summary

As you can see there are reasons why some issues that are found by RIPS might be not exploitable. Nonetheless, the information provided is very valuable as a general overview about the quality of the code and the likelihood of security incidents. Even if an issue can not be exploited at the moment, the information provided should be used to harden the code and thus decrease the likelihood of problems in the future. A single change in the code might be enough to turn non-exploitable issues into exploitable ones.

APAV Time Table