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

301
302
303
$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.

RIPS

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

643
644
645
646
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.


Follow us on Twitter to be notified when the next gift of our advent calendar is opened!

APAV Time Table

Date Author Title
24 Dec 2016 Johannes Dahse What we learned from our Advent Calendar
23 Dec 2016 Hendrik Buchwald e107 2.1.2: SQL Injection through Object Injection
22 Dec 2016 Daniel Peeren Security Compliance with Static Code Analysis
21 Dec 2016 Martin Bednorz AbanteCart 1.2.8 - Multiple SQL Injections
20 Dec 2016 Martin Bednorz Kliqqi 3.0.0.5: From Cross-Site Request Forgery to Code Execution
19 Dec 2016 Robin Peraglie osClass 3.6.1: Remote Code Execution via Image File
18 Dec 2016 Daniel Peeren Continuous Integration - Jenkins at your service
17 Dec 2016 Johannes Dahse OpenConf 5.30 - Multi-Step Remote Command Execution
16 Dec 2016 Robin Peraglie Redaxo 5.2.0: Remote Code Execution via CSRF
15 Dec 2016 Dennis Detering Guest Post: Vtiger 6.5.0 - SQL Injection
14 Dec 2016 Hendrik Buchwald The State of Wordpress Security
13 Dec 2016 Johannes Dahse phpBB 2.0.23 - From Variable Tampering to SQL Injection
12 Dec 2016 Martin Bednorz Teampass 2.1.26.8: Unauthenticated SQL Injection
11 Dec 2016 Daniel Peeren Rescanning Applications with RIPS
10 Dec 2016 Hendrik Buchwald Non-Exploitable Security Issues
9 Dec 2016 Hendrik Buchwald Precurio 2.1: Remote Command Execution via Xinha Plugin
8 Dec 2016 Martin Bednorz PHPKit 1.6.6: Code Execution for Privileged Users
7 Dec 2016 Hendrik Buchwald Serendipity 2.0.3: From File Upload to Code Execution
6 Dec 2016 Robin Peraglie Roundcube 1.2.2: Command Execution via Email
5 Dec 2016 Hendrik Buchwald Expression Engine 3.4.2: Code Reuse Attack
4 Dec 2016 Johannes Dahse Introducing the RIPS analysis engine
3 Dec 2016 Martin Bednorz eFront 3.6.15: Steal your professors password
2 Dec 2016 Martin Bednorz Coppermine 1.5.42: Second-Order Command Execution
1 Dec 2016 Hendrik Buchwald FreePBX 13: From Cross-Site Scripting to Remote Command Execution
25 Nov 2016 Martin Bednorz Announcing the Advent of PHP Application Vulnerabilities

Disclaimer: The information provided here is for educational purposes only. It is your responsibility to obey all applicable local, state and federal laws. RIPS Technologies GmbH assumes no liability and is not responsible for any misuse or damages caused by direct or indirect use of the information provided.