View Issue Details

IDProjectCategoryView StatusLast Update
0012908mantisbtsecuritypublic2015-03-15 19:58
ReporterlevelAssigned Todregad 
Status closedResolutionfixed 
Product Version1.2.4 
Target Version1.3.0-beta.2Fixed in Version1.3.0-beta.2 
Summary0012908: PHP remote code execution in install.php

mantis-1.2.4 stable from SF

PHP Injection in the install script

Steps To Reproduce

Mysql host Host Example: localhost:63306';system($_GET['cmd']);$a='1


TagsNo tags attached.


related to 0017012 closeddregad Quotes not escaped on install 




2011-04-05 08:56

reporter   ~0028529

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.





2011-04-05 10:42

reporter   ~0028536

Steps to reproduce

  1. download from SF
  2. unzip package
  3. chmod so config is writable for install script
    Ex. If your MySQL server is on the local host and running on port 63306:
  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

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



2011-04-10 22:36

reporter   ~0028582

dhx, can you confirm the issue?



2011-09-04 00:00

reporter   ~0029637

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?



2012-02-04 13:50

reporter   ~0031122

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



2012-02-06 11:15

reporter   ~0031170

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.





2012-02-06 11:39

developer   ~0031171

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



2012-02-06 18:41

reporter   ~0031177

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 :)



2012-02-07 10:06

reporter   ~0031179

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.



2012-03-06 07:16

reporter   ~0031385

Last edited: 2012-03-06 07:19

View 2 revisions

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.


2013-04-27 18:26

developer   ~0036698

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



2014-12-29 19:24

developer   ~0042079

Should be fixed now.

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

Related Changesets

MantisBT: master 38325e28

2014-12-29 19:12:19


Details Diff
Install: escape strings inserted in config_inc.php

This ensures it is not possible to inject arbitrary PHP code into the
generated config file.

Fixes 0012908, 0017012
mod - admin/install.php Diff File

Issue History

Date Modified Username Field Change
2011-04-04 11:32 level New Issue
2011-04-05 08:33 dhx Assigned To => dhx
2011-04-05 08:33 dhx Status new => assigned
2011-04-05 08:34 dhx Product Version => 1.2.4
2011-04-05 08:34 dhx Summary PHP Injection => PHP remote code execution in install.php
2011-04-05 08:56 dhx Note Added: 0028529
2011-04-05 10:42 level Note Added: 0028536
2011-04-10 22:36 level Note Added: 0028582
2011-09-04 00:00 dhx Note Added: 0029637
2011-09-04 00:00 dhx Status assigned => feedback
2012-02-04 13:50 grangeway Note Added: 0031122
2012-02-04 13:50 grangeway Status feedback => resolved
2012-02-04 13:50 grangeway Resolution open => unable to reproduce
2012-02-06 11:15 level Note Added: 0031170
2012-02-06 11:39 dregad Note Added: 0031171
2012-02-06 18:41 grangeway Note Added: 0031177
2012-02-07 10:06 level Note Added: 0031179
2012-02-20 07:18 atrol Status resolved => closed
2012-03-06 07:16 dhx Note Added: 0031385
2012-03-06 07:16 dhx Status closed => feedback
2012-03-06 07:16 dhx Resolution unable to reproduce => reopened
2012-03-06 07:16 dhx Status feedback => acknowledged
2012-03-06 07:16 dhx Target Version => 1.2.10
2012-03-06 07:19 dhx Note Edited: 0031385 View Revisions
2012-04-02 02:33 atrol Target Version 1.2.10 => 1.2.11
2012-06-06 23:54 jreese Target Version 1.2.11 => 1.2.12
2012-11-10 19:04 dregad Target Version 1.2.12 => 1.2.13
2013-01-22 09:48 dregad Target Version 1.2.13 => 1.2.14
2013-01-29 09:28 dregad Target Version 1.2.14 => 1.2.15
2013-04-12 09:57 dregad Target Version 1.2.15 => 1.2.16
2013-04-27 18:26 atrol Note Added: 0036698
2013-04-27 18:26 atrol Assigned To dhx =>
2014-02-07 18:25 dregad Target Version 1.2.16 => 1.2.17
2014-03-03 14:25 dregad Target Version 1.2.17 => 1.2.18
2014-12-05 18:34 dregadmin Target Version 1.2.18 => 1.2.19
2014-12-29 19:15 dregad Relationship added related to 0017012
2014-12-29 19:22 dregad Changeset attached => MantisBT master 38325e28
2014-12-29 19:22 dregad Assigned To => dregad
2014-12-29 19:22 dregad Status acknowledged => resolved
2014-12-29 19:22 dregad Fixed in Version => 1.3.0-beta.2
2014-12-29 19:24 dregad Target Version 1.2.19 => 1.3.0-beta.2
2014-12-29 19:24 dregad Note Added: 0042079
2014-12-29 19:25 dregad View Status private => public
2015-03-15 19:57 dregad Resolution reopened => fixed
2015-03-15 19:58 dregad Status resolved => closed