Bug #10005 RFE - security patch, to prevent plaintext passwords in config files from leaki
Submitted: 19 Apr 2005 17:40 Modified: 9 Jan 2006 14:46
Reporter: R Herrold Email Updates:
Status: Closed Impact on me:
None 
Category:Eventum Severity:S3 (Non-critical)
Version:current OS:Any (All)
Assigned to: CPU Architecture:Any

[19 Apr 2005 17:40] R Herrold
Description:

13:04  orc_orc> glen: any chance of isolating config.inc.php  and
                setup.conf.php into their own directory, so I can add a 'allow
                from localhost' only stanza on /etc/httpd.conf.d/eventum for
                them ; it would also permit simplifying upgrade instructions
                too ?
13:05  orc_orc> (similar to how Nagios does it)
13:18  jpm_> orc_orc: chance is pretty slim on that request above, maybe on
             eventum 2.0
13:19  jpm_> orc_orc: i mean, the request about separate directories for the
             config files
13:19  orc_orc> ahh

===================================

[root@emac conf.d]# pwd
/etc/httpd/conf.dScriptAlias /nagios/cgi-bin/ /usr/lib/nagios/cgi/
<Directory /usr/lib/nagios/cgi/>
   Options ExecCGI
   order deny,allow
   deny from all
   allow from 127.0.0.1
</Directory>

Alias /nagios/ /usr/share/nagios/
<Directory /usr/share/nagios/>
   Options None
   order deny,allow
   deny from all
   allow from 127.0.0.1
</Directory>

# For SSL-servers
#ScriptAlias /nagios/cgi-bin/ /usr/lib/nagios/cgi/
#<Directory /usr/lib/nagios/cgi/>
#   Options ExecCGI
#   SSLRequireSSL
#   order deny,allow
#   deny from all
#   AuthType Basic
#   AuthUserFile /site/cfg/passwd
#   AuthGroupFile /site/cfg/group
#   AuthName "nagios"
#   require group nagios
#   Satisfy Any
#</Directory>
#
#Alias /nagios/ /usr/share/nagios/
#<Directory /usr/share/nagios/>
#   Options None
#   SSLRequireSSL
#   order deny,allow
#   deny from all
#   AuthType Basic
#   AuthUserFile /site/cfg/passwd
#   AuthGroupFile /site/cfg/group
#   AuthName "nagios"
#   require group nagios
#   Satisfy Any
#</Directory>

[root@emac conf.d]#

How to repeat:
There are only seven occurances of setup.conf.php, although more of  config.inc.php
[root@ftp eventum]# grep -R config.inc.php * | wc
    183     741   14131
[root@ftp eventum]# grep -R setup.conf.php * | wc
      7      38     533
[root@ftp eventum]#                               

Curiously, there is a mismash of relative paths in effect as well, rather than an absolute path variable for each, set only one place.  There are 33 variant cases:

[root@ftp eventum]# grep -R config.inc.php * | awk -F: {'print $2'} | sort | uniq | wc
     33     324    2513
[root@ftp eventum]#

but MOST of them are the same trivial fix which would be solved with a single common absolute path variable:

[root@ftp eventum]# grep -R config.inc.php * | awk -F: {'print $2'} | sort | uniq -c | sort -n | tac
     55 include_once("config.inc.php");
     54 include_once("../config.inc.php");
     24 include_once("../../../config.inc.php");
      4 include_once("../../config.inc.php");
      4 // @(#) $Id
      3 // upgrade the config.inc.php file
      3 if (copy(APP_PATH . "config.inc.php", $backup_file) == false) {
      3 $fp = fopen(APP_PATH . 'config.inc.php', 'w');
      3     echo "Unable to create backup copy of config.inc.php. Please check your base directory is writeable and try again.";
      3     echo "Could not write the configuration information to 'config.inc.php'. The file should be writable by the user that the web server runs as. Please correct this problem and try again.";
      3     echo "Could not open the file 'config.inc.php' for writing. The permissions on the file should be set as to allow the user that the web server runsas to open it. Please correct this problem and try again.";
      3 $config_contents = implode("", file(APP_PATH . "setup/config.inc.php"));
      1     // substitute the appropriate values in config.inc.php!!!
      1 Solution
      1         return "The file 'config.inc.php' in Eventum's root directory needs to be writable by the web server user. Please correct this problem and try again.";
      1         return "Could not write the configuration information to 'config.inc.php'. The file should be writable by the user that the web server runs as.Please correct this problem and try again.";
      1         return "Could not open the file 'config.inc.php' for writing. The permissions on the file should be set as to allow the user that the web server runs as to open it. Please correct this problem and try again.";
      1     include_once("../config.inc.php");
      1 include("../config.inc.php");
      1     if (!is_writable('../config.inc.php')) {
      1     $fp = @fopen('../config.inc.php', 'w');
      1     $error = checkPermissions('../config.inc.php', "File 'config.inc.php'");
      1 Done. Your configuration file (config.inc.php) has been upgraded to version 1.5. <br />
      1 Done. Your configuration file (config.inc.php) has been upgraded to version 1.5.2. <br />
      1 Done. Your configuration file (config.inc.php) has been upgraded to version 1.4. <br />
      1     $config_contents = implode("", file("config.inc.php"));
      1     // check if config.inc.php in the root directory is writable
      1 $backup_file = APP_PATH . "config.inc.php_pre_1_5_2";
      1 $backup_file = APP_PATH . "config.inc.php_pre_1_5";
      1 $backup_file = APP_PATH . "config.inc.php_pre_1_4";
      1     APP_PATH . 'config.inc.php' => array(
      1 3) Copy over your backed up copies of config.inc.php and setup.conf.php
      1 1) Make a copy of the following files
[root@ftp eventum]#
[22 Apr 2005 13:35] Mike Schroll
How about just making the upgrade scripts rename the configs to a filename ending in .php?

That would prevent leakage of sensitive information when someone upgrades, and it leaves behind the config information, easily accessible from the web -- at well defined filenames -- 
ala
http://site.eventum/config.inc.php_pre_1_5_3
[2 May 2005 20:02] R Herrold
Date: Sat, 23 Apr 2005 14:54:50 -0400 (EDT)
From: R P Herrold <herrold@owlriver.com>
To: Bug Database <dev-bugs@mysql.com>
Subject: Re: Bug #10005 [Com]: RFE - security patch,
    to prevent plaintext passwords in config files from leaki

> How about just making the upgrade scripts rename the configs to a
> filename ending in .php?
>
> That would prevent leakage of sensitive information when someone
> upgrades, and it leaves behind the config information, easily
> accessible from the web -- at well defined filenames --
> ala
> http://site.eventum/config.inc.php_pre_1_5_3

The issue is not so much a leak during upgrades; a local user can craft a
local PHP script to sourhe and read the vaiables set in a local script.

It is the rather changes to remove the ability to REMOTELY access the
configs file by getting them out of a path which is served 'to the world'
and restricting them into a path accesible (through webserver ACL
enfircement) only to 127.0.0.1

-- Russ Herrold
[2 May 2005 20:03] R Herrold
> Just a quick note here, I was reading this page
> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/php.html
> And found the below.. This to me means that Eventum and other such programs
> should expect to have a top level public dir, and an includes that is not
> public. So the question is, do you eventum guys consider this to be
> we
[9 Jan 2006 13:46] Aleksey Kishkin
unassign it, because jpm has left mysql ab?
[9 Jan 2006 14:46] Bryan Alsdorf
The config files are not placed in a seperate directory now, but all sensitive files do now end in .php so their contents are no longer readable by the outside world.