View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012908||mantisbt||security||public||2011-04-04 11:32||2015-03-15 19:58|
|Target Version||1.3.0-beta.2||Fixed in Version||1.3.0-beta.2|
|Summary||0012908: 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
|Tags||No tags attached.|
Thanks for the bug report.
I've traced the $f_hostname parameter inside install.php:
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.
Steps to reproduce
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.
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:
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.
|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|