The XSS issue in the shard parameter appears to be resultant from a
more serious file inclusion vulnerability. This is the kind of
diagnosis error that I have mentioned in the past [1].
Notice that the error message shows that it took the "shard" parameter
and directly inserted it into a filename that it then tried to open.
In addition, the "/" is not being filtered - otherwise the </h1> would
not be there:
>Warning: main(): Failed opening 'engine/shards/<h1>just test your
>web</h1>.php'
>for inclusion
>(include_path='.:/usr/lib/php/:/usr/share/pear/') in
>/var/www/html/blur/index.php on line 108
Looking at the source for index.php in blur6ex 0.3.462, we have:
> $shard = $_REQUEST["shard"];
>...
> include('engine/shards/' . $shard .'.php');
>...
> include('engine/shards/' . $shard . '.php');
There is not any apparent cleansing of the $shard variable (based on
grep test).
So, this looks like a directory traversal issue in a PHP include
statement, so arbitrary PHP files might be included and executed using
"../" sequences. And without any apparent cleansing, it seems likely
that null character injection could be used to access files of any
extension.
NOTE - the errormsg parameter appears to be primary XSS. From
engine/shards/login.php:
> case "g_error":
> $errormsg = $_REQUEST['errormsg'];
>...
> $thisContentObj->primaryContent = "Error: " . $errormsg;
This is all based on source code inspection only - I have not
installed and tested the product.
- Steve
References:
[1] Mis-diagnosed XSS bugs hiding worse issues due to PHP feature
Bugtraq, April 1, 2006
http://marc.theaimsgroup.com/?l=bugtraq&m=114392753509966&w=2
