Non-Exploitable Security Issues


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


$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


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


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

DateAuthorTitle
24 Dec 2016Johannes DahseWhat we learned from our Advent Calendar
23 Dec 2016Hendrik Buchwalde107 2.1.2: SQL Injection through Object Injection
22 Dec 2016Daniel PeerenSecurity Compliance with Static Code Analysis
21 Dec 2016Martin BednorzAbanteCart 1.2.8 - Multiple SQL Injections
20 Dec 2016Martin BednorzKliqqi 3.0.0.5: From Cross-Site Request Forgery to Code Execution
19 Dec 2016Robin PeraglieosClass 3.6.1: Remote Code Execution via Image File
18 Dec 2016Daniel PeerenContinuous Integration - Jenkins at your service
17 Dec 2016Johannes DahseOpenConf 5.30 - Multi-Step Remote Command Execution
16 Dec 2016Robin PeraglieRedaxo 5.2.0: Remote Code Execution via CSRF
15 Dec 2016Dennis DeteringGuest Post: Vtiger 6.5.0 - SQL Injection
14 Dec 2016Hendrik BuchwaldThe State of Wordpress Security
13 Dec 2016Johannes DahsephpBB 2.0.23 - From Variable Tampering to SQL Injection
12 Dec 2016Martin BednorzTeampass 2.1.26.8: Unauthenticated SQL Injection
11 Dec 2016Daniel PeerenRescanning Applications with RIPS
10 Dec 2016Hendrik BuchwaldNon-Exploitable Security Issues
9 Dec 2016Hendrik BuchwaldPrecurio 2.1: Remote Command Execution via Xinha Plugin
8 Dec 2016Martin BednorzPHPKit 1.6.6: Code Execution for Privileged Users
7 Dec 2016Hendrik BuchwaldSerendipity 2.0.3: From File Upload to Code Execution
6 Dec 2016Robin PeraglieRoundcube 1.2.2: Command Execution via Email
5 Dec 2016Hendrik BuchwaldExpression Engine 3.4.2: Code Reuse Attack
4 Dec 2016Johannes DahseIntroducing the RIPS analysis engine
3 Dec 2016Martin BednorzeFront 3.6.15: Steal your professors password
2 Dec 2016Martin BednorzCoppermine 1.5.42: Second-Order Command Execution
1 Dec 2016Hendrik BuchwaldFreePBX 13: From Cross-Site Scripting to Remote Command Execution
25 Nov 2016Martin BednorzAnnouncing 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.

Tags: php, security, false-positives,

Comments

comments powered by Disqus