[VIM] Maybe SpC-X was right after all...

Steven M. Christey coley at linus.mitre.org
Mon Jun 26 22:05:00 EDT 2006

I've been on what felt like a wild goose chase for a couple months, with
all these disclosures that seem to handle include statements with values
with static values.

Turns out that at least some of it could be dynamic variable evaluation,
which can overwrite the initial static value if it's called after the

Now we need to look more closely at SpC-X and other issues...

- Steve

---------- Forwarded message ----------
Date: Mon, 26 Jun 2006 22:01:01 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: bugtraq at securityfocus.com
Subject: Re: [ECHO_ADV_34$2006] W-Agora (Web-Agora) <= 4.2.0 (inc_dir)
    Remote File Inclusion

>Successful exploitation requires that "register_globals= Off ".

That seems very strange, doesn't it?

Especially if you look at the source code.

Let's start with search.php, one of the vulnerable vectors:



  require ("init.inc");

and in init.inc:

  require ("globals.inc");


  require ("$inc_dir/misc_func.$ext");

and in globals.inc:

  if (defined("_GLOBALS")) return;
  define('_GLOBALS', 1);


  $inc_dir    = 'include';

So - how could an attacker POSSIBLY modify the $inc_dir variable AFTER
it's set to a static value and when register_globals is off?

The answer is dynamic variable evaluation, which I posted about a
couple months ago at:


If we look more closely at globals.inc, later on, we see this:

  if (!get_cfg_var("register_globals") ) {
      include "include/register_globals.$ext";

and then if we look at register_globals.php, we see code like this:

	if (isset($HTTP_GET_VARS)) {
		while ( list($var, $val) = each($HTTP_GET_VARS) ) {


This highlights the insidious nature of dynamic evaluation.

So - for those of us who have been questioning vulnerability reports
because we were seeing static values being set in include files - we
need to see if dynamic variable evaluation happens *after* the
variable is set, but *before* it's used.

Nasty, nasty stuff...

- Steve

More information about the VIM mailing list