[VIM] clarification of "VihorDesign" (not VihorDesing) issues

[Steven M. Christey]

A typo in a Bugtraq post is making the rounds through various vuln
dbs.  I also did some followup analysis and found some interesting/odd
things, plus a question.


Ref: VihorDesing Script Remote Command Exucetion And Cross Scripting
Attack
  http://www.securityfocus.com/archive/1/archive/1/428737/100/0/threaded


==== product/vendor name ====

If you access the vendor web site as specified in the Bugtraq post:

  http://www.vihor.de

The zip file is called "vihordesign"

and some text near the top of the page says ":: ViHor :: Design ::"

If you Google, the company seems to be "ViHor Design".

For humor, type "vihordesing" into Google and compare the results to
"vihordesign".

I don't read German, but it sounds like this is a web design company,
which might argue for exclusion from a vuln DB.  However, for CVE's
purposes, since there's a distinct download of the code, it counts.

... which led me to download and inspect the source for the claimed
"remote execute" and XSS issues.

==== source code inspection ====

vihordesign_1.0.6/index.php has the following code:

  if ($page=="") $page="mainfile.php";
  ...
  $fd = fopen($page, "r");
  while (!feof($fd)) {
  echo fgets($fd, 10096);
  }

A "grep" shows no other use of $page in any other file in the 1.0.6
distribution.

Since fopen() can support remote URLs, we have what might appear to be
a classic PHP remote file issue.  However, this is in an fopen(), and
it's not being fed into an include/require statement; it's just
echoing the results back to the client.  So I don't see how it can be
used for code execution.

But I'm not that familiar with PHP, so maybe someone else can clarify.
Can the output of "echo" get interpreted as PHP if it's echoing a
"<?php" string?

Or, maybe an older version is affected for code execution.  HOWEVER, I
downloaded the code for 1.0.3 and it's got the same basic code as
above.

Now... the above code is clearly vulnerable to XSS, since the fopen()
output is echoed directly to the web client without any HTML
conversion.

Interestingly though, that's not the attack vector suggested by the
researcher in the original Bugtraq post, who used <script> tags in the
page parameter.  Since we now know that "page" is only used in an
fopen call, the "<script>" input must be triggering a verbose PHP
error on an fopen failure, which doesn't quote the HTML tags.

So we have a single parameter with 2 distinct methods of injection for
XSS, although they involve the same underlying function call.

PHP sure is fun!

- Steve