Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability
Hey Steve,
Steven M. Christey schrieb am Mon, 14 Aug 2006 17:54:59 -0400:
>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.
I did so, but I thought it was not necessary to write
it in my first mail.
The same with the other reported "non-vulnerabilities".
Only in one point I'm not 100% sure: In miniBloggie an
inclusion in a function seems possible. But I see no
way to call this "poisoned" function after that, so
there is no way to execute the included evil code.
Or I'm wrong?
>See [1] for an example where this occurred in the real
>world (although it still seems to be rare).
But it's possible, you are absolutely right.
As you wrote in [1] - very nasty thing.
That, combined with register_globals set to on, could
grow grey hairs in masses. :-)
>There are no such constructs in 0.7.20060401, so this
>still looks like an invalid report.
Exactly.
>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.
I didn't look at them, I only checked the reported
version.
>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.
For something called config* a normal behavior.
>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.
Indeed. Every script could be modified in a way, that
it's vulnerable to something. That's in the nature of
all scripting languages.
If I had to check something I always take a version "out
of the box" to be sure it's not modified.
In a production environment the combination of product and
all modifications and configuration had to be safe. But
for a test of a program only the program counts.
Regards
Carsten
>[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
>
--
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz
<http://www.ceilers-it.de>