bugtraq - Re: JetBox cms (search_function.php) Remote File Include

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 30 Aug 2006 20:39:25 +0200
From: "Carsten Eilers" <ceilers-lists@....de>
To: "Steven M. Christey" <coley@...re.org>,
	<bugtraq@...urityfocus.com>
Subject: Re:  JetBox cms (search_function.php) Remote File Include

Hi Steve,

Steven M. Christey schrieb am Tue, 29 Aug 2006 19:57:13 -0400:

>Frank Reissner said:
>
>>  //comments
>>  
>>  function phpdigSearch(){
>>  
>>  Line: 423 <?php include $relative_script_path.'/libs/htmlheader.php'
>>  ?>
>>  
>>  ...
>>  }
>>
>>Please explain us how that should be exploited.
>
>While this statement appears to be in a function declaration, there
>would be nested "<?php" tags - a parse error, at least in my PHP 4.

I tested it with PHP 4.3.10 on Mac OS X with Apache 
1.3.33 and the script does nothing. No parse error,
no results. Only a white page.

Local and remote file inclusion tests shows no results,
too.

>So, this code is "live" within the script, somehow.

Maybe. I find it hard to read, some more tabs would
be a got think. :-)

I put a few 'echo "Test ...";'-Lines in the code, that 
one after the last } is the only one wich is executed. 
Bad test, I know, but a "quick$dirty" way to look, which
parts are executed and which not. 

>And, in fact, if we look at the surrounding context (at least for my
>copy of search_function.php), we have this:
>
>        else {
>            $t_strings = array_merge($t_mstrings,$t_fstrings);
>            phpdigParseTemplate($template,$t_strings,$table_results);
>        }
>    }
>    
>    else {
>    ?>
>    <?php include $relative_script_path.'/libs/htmlheader.php' ?>
>    <head>
>    <title><?php print $title_message ?></title>
>    <?php include $relative_script_path.'/libs/htmlmetas.php' ?>
>
>
>Notice the "?>" in front of the include statement, which closes off
>the first bit of executable code.

I'm not sure about the defintion of function-definitions.
In a normal script it's possible to mix <?...?>-PHP-Code
and HTML-Code, for example if there are many HTML-tags which
otherwise hat to be echo'ed in PHP. Is this possible inside
a function-definition? The PHP-Manual says nothing about
this (or I did'nt found it :-) ).

>So, this looks like it could be exploitable using a direct request to
>search_function.php, since at the point of the include, the
>$relative_script_path variable is *not* initialized.

It someway looks like this, yes.

I tried it with no results, but failing tests are no reliable 
proof for non-inclusion.

But I tend to the conclusion, the whole script is really only
one function-definition.

>Finally - the original pathname suggested a possible third party
>module, and in fact, the affected file and referenced code matches
>that of phpDig 1.8.8, so this is probably a vulnerability in phpDig
>instead of Jetbox.

I take a quick look at PhpDig 1.8.8. 
The search_function.php is mostly the same, here we found
a comment:

// $relative_script_path set in search.php file

Tests (remote and local inclusion) shows no effects. But as
above... no proof. 

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>