#179 activities/workflow-activities.php remote file inclusion


Quoting CVE-2008-3399 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3399):

PHP remote file inclusion vulnerability in activities/workflow-activities.php in XRMS CRM 1.99.2, when register_globals is enabled, allows remote attackers to execute arbitrary PHP code via the include_directory parameter.

* BUGTRAQ:20080725 XRMS 1.99.2 (RFI/XSS/IG) Multiple Remote Vulnerabilities
* URL:http://www.securityfocus.com/archive/1/archive/1/494754/100/0/threaded
* MILW0RM:6131
* URL:http://www.milw0rm.com/exploits/6131
* XF:xrmscrm-workflowactivities-file-include(43992)
* URL:http://xforce.iss.net/xforce/xfdb/43992


  • Neil Williams

    Neil Williams - 2008-10-17

    The first thing that could be done here is to include a check for register_globals on this page. If enabled either present a warning or disable the page. Is register_globals required by XRMS? I don't think so but would like confirmation.

    Next step would be to remedy the root cause of the problem. However, the description of the vulnerability is not specific enough for me to pin point the problem. Any further information would be grateful.

    Finally, once a remedy is in place, should we update the sites which have announced this vulnerability? If yes, how?

  • Neil Williams

    Neil Williams - 2008-10-18
    • assigned_to: nobody --> metamedia
  • Neil Williams

    Neil Williams - 2008-10-18

    I've now completed an initial analysis of this vulnerability. It is real and spread through out the system, not just the page quoted. A root cause remedy is simple but would require edits to scores of scripts. The bug shall remain open until this work is done. In the meantime:

    It is imperative that sites have REGISTER_GLOBALS OFF

    N.B. the risk is only for sites that have register_globals ON.

  • Brian Peterson

    Brian Peterson - 2008-10-20

    I would certainly approve of completely disabling XRMS for sites with register_globals set to ON. There is no reason to run PHP in this insecure mode. XRMS is enterprise software, and should be run on servers where the administrator has the control to turn off insecure settings in the server config.

    - Brian

  • Neil Williams

    Neil Williams - 2008-10-21

    I have committed a small change to CVS which will reduce risk around this vulnerability. However, the root cause has not been addressed => bug still OPEN.

  • freddysf

    freddysf - 2009-08-06

    register_globals has been officially DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Read more here: http://us.php.net/manual/en/security.registerglobals.php

    If the XRMS experts agree a small code may be placed in vars.php to abort XRMS if register_globals is on. For example consider the following patch for include/vars.php, an adaptation of osCommerce's check on register_globals:

    --- ../../current_xrms/include/vars.php 2009-08-06 16:21:16.000000000 -0400
    +++ vars.php 2009-08-06 15:30:35.000000000 -0400
    @@ -15,6 +15,12 @@
    * $Id: vars.php,v 1.46 2009/02/14 18:01:16 randym56 Exp $

    +// check if register_globals is enabled.
    +// idea adapted from oscommerce includes/application_top.php
    +if (function_exists('ini_get')) {
    + !ini_get('register_globals') or exit('<H1>XRMS Server Requirement Error:</H1> register_globals is enabled in your PHP configuration. Please contact your System Administrator and report this issue.');
    * Database Connection info for XRMS system

  • 360team.ca

    360team.ca - 2011-03-03
    • labels: 658310 -->
  • 360team.ca

    360team.ca - 2011-03-03

    Considering the fate of register_globals in recent versions of PHP, it is probably safe to assume that no system administrator worth their word these days would be running any PHP scripts, let alone a system containing vital corporate information like XRMS on a server with PHP's register_globals enabled.

    While XRMS already employs at least a couple of protection mechanisms against remote file inclusion (and other) attacks, it is questionable whether XRMS's level of protection in the scenario of it being installed and run on outdated servers with insecure configurations should be considered a bug.

    Idiot-proofing for users is one thing. Idiot-proofing for administrators is, well... a feature request!


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks