[VIM] Bogus - [c_r_ck at hotmail.com: Lazarus Guestbook (admin.php)Remote File Include Expliot]

[Steven M. Christey]

Below is a writeup from a CVE analyst that suggests that versions *before*
1.7.3 were vulnerable, and that it got patched:

http://carbonize.co.uk/Lazarus/Forum/index.php?topic=1164.0


ACCURACY: 1.7.3 is not vulnerable. Its admin.php has these four code
sections in this safe order: (1) extract all GPC variables using the
typical "$$name = $value" approach, (2) check for an inclusion attack:
if (isset($include_path)) { die("Hacking Attempt!"); }, (3) define
include_path before use: $include_path = dirname(__FILE__);, (4) use
$include_path in various require_once and include statements within
the application. The last previous available version (1.7) of
admin.php uses a different ordering. Based on the vendor's comments
below, this unsafe ordering apparently persisted up until 1.7.2. The
unsafe ordering is: (1) $include_path = dirname(__FILE__);, (2)
immediately use $include_path in require_once statements (this is OK),
(3) extract all GPC variables using the typical "$$name = $value"
approach, thus overwriting $include_path, (4) call an external
constructor, located in the template.class.php file: new
gb_template($include_path);, (5) the gb_template constructor sets
$this->root_dir to the unsafe value of $include_path, (6) other
functions in the gb_template class use $this->root_dir for inclusion,
e.g., get_content calls include $this->root_dir.'/lang/english.php';,
(7) there is always a call to this get_content function within the
main flow of control in admin.php. In other words, admin.php in
versions before 1.7.3 doesn't allow remote file inclusion within this
file itself, but does trigger remote file inclusion in a different
file.


ACKNOWLEDGEMENT: The vendor says "March 03, 2007 ... An [sic] cross
site scripting vulnerability exists in Lazarus and so I have released
1.7.3 to patch it." The vendor apparently misunderstands the term
cross site scripting, and actually meant that a php-include
vulnerability was fixed. The vendor also (on 20070304) responds to a
request about how to manually patch by saying "Open admin.php and find
the ... if (!isset($PHP_SELF)) ... block ... and move it to before
where $include_path is set. Just download the update and look at
admin.php to see what I mean." In other words, the vendor is
indicating that include_path must be set safely after the GPC variable
extraction occurs. The application only uses include_path in
require/include statements. It does not print out the value of
include_path. Thus, it is fairly clear that the vendor was not
actually talking about an XSS vulnerability.