bugtraq - Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Mon, 14 Aug 2006 17:54:59 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: ceilers-lists@....de
Cc: bugtraq@...urityfocus.com
Subject: Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability

Carsten Eilers said:

> Take a look at the top of cal_config.inc.php:
> 
> # adjust the '$calpath'.
> # hardcode it if detection does not work and comment out the remaining
> # code.
> #
> # $calpath = "C:\\PHP\\calendarix\\demo\\" ;
> 
> $calpath = dirname(__FILE__) ;

When doing post-disclosure analysis on "grep-and-gripe" research like
this, you need to make sure that after this initialization, that the
variable doesn't get overwritten before the affected require
statement, e.g. if dynamic variable evaluation is used a la "$$varname
= $_GET[input]".  That means looking within cal_config.inc.php, as
well as any other files that are included/required, before we get to
the vulnerable require statement.  See [1] for an example where this
occurred in the real world (although it still seems to be rare).

There are no such constructs in 0.7.20060401, so this still looks like
an invalid report.  I also checked 3 other versions, all the way back
to the first beta release (0.1.20020905), and $calpath is initialized
to a constant value with no possible modifications before the affected
require statement.

One thing to note is the developer's comment "hardcode [$calpath] if
detection does not work and comment out the remaining code."  The
README also makes it clear that some manual modification of this file
might occur.

So, it's possible that some Calendarix administrators manually changed
cal_config.inc.php in a way that would allow $calpath to be modified
externally.  But then that would be a vulnerability in the site's own
configuration, not the product.

- Steve

[1] BUGTRAQ:20060626 Re: [ECHO_ADV_34$2006] W-Agora (Web-Agora) <=
    4.2.0 (inc_dir) Remote File Inclusion
    http://seclists.org/bugtraq/2006/Jun/0679.html