Bugtraq mailing list archives
Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability
From: "Carsten Eilers" <ceilers-lists () gmx de>
Date: Tue, 15 Aug 2006 10:59:01 +0200
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>
Current thread:
- Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability sh3ll (Aug 12)
- Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability Carsten Eilers (Aug 14)
- <Possible follow-ups>
- Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability Steven M. Christey (Aug 14)
- Re: Calendarix <= 0.7 (calpath) Remote File Inclusion Vulnerability Carsten Eilers (Aug 15)