Thanks for the bug report.

I've traced the $f_hostname parameter inside install.php:

1. If configuration exists, retrieve the database hostname via a config_get() call. Otherwise grab the supplied hostname string from the parameters the user sent to the page with a gpc_get() call.

2. Pass the value of $f_hostname from step (1) directly to the ADOdb Connect() function.

3. ADOdb passes off the connection request to the _connect() function of the appropriate backend driver (in this case you mentioned MySQL, so that is what I've looked at).

4. The _connect() function passes the same $f_hostname value from step (1) to PHP's mysql_connect() function.

I've tried injecting stuff into the "hostname" field on admin/install.php without any PHP injection taking place. From my tracing above I wouldn't expect issues with the hostname field anyway.

I've also grepped the source of both 1.2.x and 1.3.x branches for system(), exec(), proc_open(), proc_exec() and shell_exec() and confirmed that none of these usages (we try to limit it as much as possible) are related to the installation script and database hostnames.

Are you able to confirm whether you're testing against a "pure" version of mantisbt-1.2.4 (extracted freshly to a new directory rather than dumped on top of an existing installation)?

If the issue is still reproducible, are you able to supply more detailed instructions on how I can reproduce the issue? I'm not sure how the install script, injection string and URL from your original description tie together.

Thanks,

David

Steps to reproduce

1. download from SF
2. unzip package
3. chmod so config is writable for install script
4. http://www.example.com/directory/admin/install.php
   (YOU NEED A VALID MYSQL SERVER)
   Ex. If your MySQL server is on the local host and running on port 63306:
   localhost:63306';system($_GET['cmd']);$a='1
5. The above would be a your Mysql Host on the install page
6. Fill out the rest of the config with valid information and finish it
7. Attack URL http://www.example.com/config_inc.php?cmd=id

Output: uid=48(apache) gid=48(apache) groups=48(apache)

dhx, can you confirm the issue?

Sorry for the delay in responding.

grep -Rn cmd *

returns nothing of interest.

In other words, system($_GET['cmd']) doesn't exist in the codebase (both master and master-1.2.x branches).

Can you please provide the download URL you're using to obtain MantisBT?

No feedback since september, and as dhx says, we don't use 'cmd' anywhere - so marking as resolved - no change required unless more information appears

this was already patched.

it wasn't that system() was being used it was that your install.php file was allowing anonymous users to write arbitrary php code to the php based configuration file which can then be directly executed to leverage that attacker created code. In the case I disclosed, from an attacker perspective I used that vulnerability to inject system() into the config file, then directly accessed that file. this was patched by directly preventing the execution of the config file, however An attacker still has the ability to inject arbitrary php code into the configuration file.

i will be releasing a tool that automatically exploits this type of vulnerability later in the year, which may be of benefit for you to run against your software.

Thanks

Level

Seems to me that making the config file writable is a silly thing to do anyway.

I still can't reproduce this - however it would still be possible to try to access config_inc.php directly in some cases.

However, given that the only user input we take to modify install.php is the host/user/pass combination that we then use to connect to the database (for an installation), i'm not that sure how one would get to 'exploit' this - as install.php only creates the config file on a new install, and would need to contain valid sql connection details.

On that basis i'm not sure I'd consider it a real issue - if someone can download and extract mantis to do a new installation to create a config file - i'd probably be more worried about the fact they've already got access to the server :)

you will not be able to reproduce it now. between the time frame of it being reported and now (roughly a year) you have added code to the beginning of the config file to prevent direct execution. attacker controlled code can still be injected into that file, it just can not be executed.

In addition, the issue is not with individuals who want to install mantis on a fresh machine. It is with the people that have not removed their install file, whether it be out of insanity, or just plain forgetfulness.

Lastly, this does require valid mysql credentials. In the fields where this information is typically inserted by the administrator, if you were to inject php code that would complete the statement for the sql credentials then insert arbitrary php code it will output the config file. that is unless something else has changed since I last saw it, however i used fairly recent code of yours in a presentation elaborating on this issue. This is not uncommon, you are not alone in the boat, many other open source projects have the same issue.

This should be reopened because the issue level has kindly explained in greater detail is still applicable to the 1.2.x branch (and possibly 1.3.x because the sample config_inc.php can be called directly).

The threat on injection via install.php is very low because this file should only be on the server (accessible) during the initial stages of installation. We have warnings in place that check for install.php after installation and warn the administrator that they need to delete the 'admin' directory.

Furthermore, the analysis I performed before (which Paul has checked) indicates that injection via the database hostname field will fail because ADOdb needs to successfully connect to the database prior to MantisBT writing the value to the configuration file.

However, saying this, I think we need to make the following fixes just to be sure:

1. Check install.php to ensure that any writes made to config_inc.php have properly escaped values to prevent raw PHP code entering the configuration file.

2. Prevent config_inc.php being included from outside of the MantisBT environment. Also see about backporting the stronger inclusion checks on the _inc.php files that the 1.3.x branch has implemented.

Removed assignment. dhx will not contribute to this issue in near future.

Should be fixed now.

Note - targetting 1.3.x, as the likelyhood of this happening is very low, so not worth backporting.