I checked the code live on a webserver - it definitly does not work. And the '?><?php' does not change anything it's only one big function like the name search_function.php also describes. They only use it to embed html-code into the function o_O The function is never called in search_function.php, $relative_script_path is also initialized in the function header if the function would be called so no way in my eyes. -----Ursprüngliche Nachricht----- Von: Steven M. Christey [mailto:coley@xxxxxxxxx] Gesendet: Mittwoch, 30. August 2006 01:57 An: bugtraq@xxxxxxxxxxxxxxxxx Betreff: Re: AW: JetBox cms (search_function.php) Remote File Include 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. So, this code is "live" within the script, somehow. 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. 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. 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. - Steve
