This may also be used to conduct Cross Site Scripting attacks. Example:

http://bugs.mantisbt.org/core/database_api.php?g_db_type=<h1>hi</h1>

Hi joxeanpiti,

I've committed a fix to our CVS that fixes this issue (amongst other things)

RCS file: /cvsroot/mantisbt/mantisbt/core/database_api.php,v
retrieving revision 1.42
retrieving revision 1.43

When Sourceforge's public cvs catches up with real life, you'll be able to see the patch at http://cvs.sourceforge.net/viewcvs.py/mantisbt/mantisbt/core/database_api.php under version 1.43.

At the moment, this patch will appear in 1.0.0RC1 (which we plan to release in the next few days). Instead of using $g_db_type directly, we call config_get('db_type'). This function is undefined if you call database_api directly, so I believe should resolve this issue.

The current behaviour of our new install.php is to treat register_globals being enabled as a fatal error (albeit this version is not yet released), with check.php which checks the setup of a mantis installation e.g. mail, database etc also treats register_globals as a fatal error.

I've included Victor in on this issue, and will leave it up to him whether this warrants releasing a patched version of 0.19.2.

When sf.net's viewcvs starts showing version 1.43, please take a look and see if you believe that the new version resolves your issue.

Thanks
Paul

When sf.net's viewcvs starts showing version 1.43, please take a look and see if you believe that the new version resolves your issue.

Of course. And one question: all prior versions are vulnerables as well, right?

Verified. Version 1.43 of <mantis_dir>/core/database_api.php fixes the problem.

It would be useful if you can include the fix for the security problem as a note in this issue. We can then decide to port it back to 0.19.2 or just make a post to notify users about it and how it can be fixed. Ideally, the fix should be as simple as possible to explain and apply.

It would be useful if you can include the fix for the security problem as a note in this issue.

Ok. I will publish it today (if I can).

I have been attached a patch that works for (any?) prior versions as well as the current of Mantis BT.

hi joxeanpiti,

Unfortunately, that won't quite work ->

It'll work with Mantis + PHP 4.1 and above

It won't work with Mantis + PHP 4.0.6, as $_REQUEST only came into existance in PHP 4.1 and above.

I'd anticipate that in 0.19.2, the simplest 'patch/hack' would be to replace:

$g_db = $db = ADONewConnection($g_db_type);

From database api, with:

$g_db = $db = ADONewConnection( config_get( $g_db_type ) );

Although, i've not verified this in anyway.

As security vulnerabilities go, unless i'm missing something else, this seems like a 'minor-medium vulnerability', which could be exploited more through social engineering.

Given the following:

a) you know of a public instance of mantisbt ( < version 1.0.0RC1 i.e. all current releases)
b) The /core/ directory lives in a public location on the webserver
c) There is not a .htaccess file or otherwise protected the /core directory.
d) The server is running with register globals off

Then you can:

a) Provide a link, which you'd then need to persuade a user to manually visit, and then use in a cross site scripting attack.
b) Attempt to locate a username and password for a mysql (or other) database server. Albeit, if you did find a valid username/password/host for the mantis database, without finding another vulneribility, the control of g_db_type would not allow you to run sql commands against the database - i.e. one would need to do a brute force attack to gain a username/password, then find some other means to remotely access the database to run sql commands, with good practice being to firewall remote access to database servers.

This code flaw exists in the following releases:

1.0.0a3
1.0.0a2
1.0.0a1
0.19.2
0.19.1
0.19.0
0.19.0RC1
0.19.0a2
0.19.0a1

I introduced this issue in http://cvs.sourceforge.net/viewcvs.py/mantisbt/mantisbt/core/database_api.php?r1=1.20&r2=1.21 which was March 2004.
Versions 0.18.3 and below would not be affected.

wonders if anyone agrees or disagrees with that analysis

Paul

As security vulnerabilities go, unless i'm missing something else, this seems like a 'minor-medium vulnerability', which could be exploited more through social engineering.

Yes. This is clearly a "disclosure", not a directly exploitable flaw. To exploit it you need to use any kind of social engineering.

I have been attached a POC about the issue and a modified patch.

Fixed in CVS.