5 minutes of glory

I have noticed over the couple last weeks that the amount of vulnerabilities being discovered in PHP related products have soared. This might have been a good thing if these vulnerabilities weren’t sometimes fictitious.

Take this example:
Smarty-2.6.1 Remote File Include Vulnerabilities

The poster of the vulnerability mentions these lines of code as being vulnerable:
require_once ‘./config.php’;
require_once SMARTY_DIR . ‘Smarty.class.php’;
require_once ‘PHPUnit.php’;

And further says that by passing:

He is able to cause the PHP code to include arbitrary code. The vulnerability is simply not there, credit is due to J. Carlos Nieto for noting it first.

Is this a single incident? No, another example is a vulnerability titled:
gcards (languagefile) Remote File Include

Where the author of the advisory doesn’t specifically state where the vulnerable code is located at, but only provides a proof of concept:
gcards/admin/addnews.php?languagefile=shell code

Looking into addnews.php you can notice the following line:

Does this mean that languagefile value affects languageFile parameter being used in the include_once? if the PoC is no typo, then no it doesn’t affect that parameter.

If the PoC is a typo and the PoC should have contained langaugeFile as the name of the parameter, still no, if you look into the code closer you will notice that, the following files precede the call to languageFile:
include_once(‘../inc/adodb300/adodb.inc.php’); # load code common to ADOdb

and the config.php file specifies:
$languageFile = ‘language_en.php’;

Meaning the product isn’t open to attack through this parameter, credit is due here for str0ke for noting it first.

Last but probably not really the last one:
PhpBB 2.0.10 (groupcp.php) Remote File Include Vulnerability

The author of the advisory mentions:
include($phpbb_root_path . ‘includes/page_header.’.$phpEx);

As the code being vulnerable, and /groupcp.php?phpbb_root_path=shell.txt? as being the attack vector, beside the fact that version 2.0.10 is more than 2 years old :) a check through the code reveals that a call to (at the very beginning of the file):
$phpbb_root_path = ‘./’

Stops any such attack from occurring, credit is due to NeoThermic for noting it first.

Does it mean that all vulnerabilities are fake? no, some are true, but there is an increasing sense – at least by me – that people are releasing without testing, or maybe they are even using Google’s codesearch to discover these vulnerabilities and never bother to test them thoroughly.

  • http://prdelka.blackart.org.uk prdelka

    would be intresting to see the number of fake vulnerabilities posted since google codesearch was made available compared to those before. i cant wait until there is a google splint!

  • Tyop

    Thx a lot.
    Can we talk about xss now?

    A french troll-er

  • zeroday

    yeah, str0ke from milw0rm.com gets pretty annoyed at how many include vulns have been showing up fake since codesearch has been noticed.
    a lot more testing a poc’s need to be done.

  • sunshine

    str0ke is a very cool guy.

  • noroot

    str0ke is ok, guess assholes will always complain about people doing their work for free…

  • Tyop

    maybe I haven’t the same definition of “work”.

  • http://www.BeyondSecurity.com noam

    Another one:
    “phpMyConferences_8.0.2 Remote File Inclusion

    $lvc_include_dir = ROOT_DIR_PATH.”common/visiteurs/include/”;


    And Tamriel mentions:
    “Are you kidding me? How can you use lvc_include_dir when it`s defined
    one line above? And don`t tell that you can use ROOT_DIR_PATH instead of
    lvc_include_dir …”

    Point proven :)

  • http://www.BeyondSecurity.com noam

    More samples:
    phpAdsNew-2.0.8 <= (adlayer.php) Remote File Include

    Sorry this report is bogus..
    the only require/include statement that utilizes that variable is line 188:

    The only possibility is local file include, with null byte bug in php interpreter.

    But local file include is thwarted with a regular expression.

  • http://www.BeyondSecurity.com noam

    And more:
    “Ban v0.1 (bannieres.php) File Include

    Please, read source code better!
    At line 11 the variable $chemin is setted as “.”

    Line 11:
    $chemin = “.” ;

    Hower a security issue could be found at line 26 and line 32 where a sql injection is possible due to uncheked $id variable”

    Where there is actually a vulnerability that wasn’t originally reported :)

  • http://cve.mitre.org Steve Christey

    This “grep-and-gripe” problem has existed for a while and seems most prominent in file inclusions. Besides Google code search, there is strong evidence (to me anyway) that it’s a relatively small group of people who are using and sharing the same flawed research techniques.

    Noam – since RFI is so powerful, and it’s so easy to find relative to other issues like SQL injection, it’s not a big surprise that many of these people don’t find other issues. They probably don’t care.

    These issues can be tracked as “** DISPUTED **” within CVE and as Myth/Fake within OSVDB.

  • k