[VIM] 4images fix - but for which issue?

[Steven M. Christey]

http://www.4homepages.de/forum/index.php?topic=11877.0

  The new version 1.7.2 has just been released and contains a few new
  features and a lot of bugfixes as well as all security fixes. We
  recommend all users to update to the current version. All changes
  and features are listed in "docs/Changelog.txt".

Since CVE-2006-0899 is a retrogod issue, and that was released on
March 1, and this fix was on March 2, that *might* be the proper fix.

CVE-2006-2011 was announced April 20, but it's for version 1.7.  No
apparent coordinated disclosure, so 1.7.2 might still be vulnerable.

Clicking through a couple links, we see that 1.7.1 is still available
for download, and 1.7.2. is available too.

Do a diff -r and we get 5000 lines of diffs.  ugh.

grep for "template" doesn't yield anything interesting... so either
the retrogod issue wasn't fixed in the obvious way, or maybe there was
some deeper fix/redesign that isn't findable by a grep or two.

In both 1.7.1 and 1.7.2 index.php, we have:

  if (isset($HTTP_GET_VARS['template']) || isset($HTTP_POST_VARS['template'])) {
    $template = (isset($HTTP_GET_VARS['template'])) ? basename(stripslashes($HTTP_GET_VARS['template'])) : basename(stripslashes($HTTP_POST_VARS['template']));
    if (!file_exists(TEMPLATE_PATH."/".$template.".".$site_template->template_extension)) {
      $template = "";
    }
    else {
      $main_template = $template;
    }
  }


So, maybe the traversal is fixed elsewhere... or maybe not.  Can't be
sure.


So how about the Qex XSS?  Looking at register.php in 1.7.1 we have:

  $user_name = (isset($HTTP_POST_VARS['user_name'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_name'])) : "";
  $user_name = ereg_replace("( ){2,}", " ", $user_name);
  $user_name = str_replace('<', '', $user_name);
  $user_name = str_replace('>', '', $user_name);


So this looks like this is stripping the main characters being used in
Qex's exploit.  However, Qex reported the XSS in 1.7, so maybe this
got fixed in 1.7.1... but Secunia reports it was confirmed in 1.7.2,
so maybe I'm missing something entirely.

Source code inspection can only get you so far :)

- Steve