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-prev] [day] [month] [year] [list]

Date: Tue, 15 Aug 2006 10:59:01 +0200
From: "Carsten Eilers" <ceilers-lists@....de>
To: "Steven M. Christey" <coley@...re.org>
Cc: <bugtraq@...urityfocus.com>
Subject: 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>