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>
