[VIM] CuteNews 1.3.* Remote File Include Vulnerability

Steven M. Christey coley at mitre.org
Tue Aug 29 18:23:32 EDT 2006

I was going to send this to Bugtraq, but does anybody else have ideas?

Ref: http://www.securityfocus.com/archive/1/archive/1/444385/100/0/threaded

I can't see where the vulnerability is.

At the very least, the source code being referenced does not have the
problem, although the real problem might be somewhere else.

from search.php, this source code was quoted:

>$cutepath = __FILE__;

__FILE__ is a constant, set to the script's pathname.  It does not
include the query string.  So, it's not controlled by the attacker at

>$cutepath = preg_replace( "'\\\search\.php'", "", $cutepath);
>$cutepath = preg_replace( "'/search\.php'", "", $cutepath);

The preg_replace() use constant values, just to strip the filename
from the end, to get the base pathname.


Since $cutepath is a constant, uncontrolled value, this statement will
only look in the expected place for inc/functions.inc.php - so the
vulnerability can't be here.


So - given the above situation, how could this attack work?

Later in search.php, there are other calls to file() and and require()
that use $cutepath, so maybe $cutepath got overwritten somewhere.

Well, let's look at inc/functions.inc.php, since that's what's being

>// bad practice, i know
>if ($_GET)              {extract($_GET, EXTR_SKIP);}

OK - so, maybe the "cutepath" parameter would be overwritten.

But - the EXTR_SKIP says "If there is a collision, don't overwrite the
existing variable."  So, since $cutepath already exists, it shouldn't
be overwritten... right?  (I tested this on my local PHP 4.x, and
EXTR_SKIP is honored even when it's in an include file and the
variable was defined in the original file).

- Steve

More information about the VIM mailing list