| Anonymous | Login | Signup for a new account | 2010-02-08 20:46 EST |  |
| Main | My View | View Issues | Change Log | Roadmap | Wiki | ManTweet | Repositories |
| View Issue Details [ Jump to Notes ] [ Wiki ] | [ Issue History ] [ Print ] | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |
| 0005956 | mantisbt | security | public | 2005-07-16 19:34 | 2006-10-09 11:55 | |
| Reporter | joxeanpiti | |||||
| Assigned To | vboctor | |||||
| Priority | normal | Severity | major | Reproducibility | always | |
| Status | closed | Resolution | fixed | |||
| Platform | OS | OS Version | ||||
| Product Version | 0.19.2 | |||||
| Target Version | Fixed in Version | 1.0.0rc1 | ||||
| Summary | 0005956: Database system scanner via variable poisoning | |||||
| Description | If the 'register_globals' directive is enabled the script located at <mantis_dir>/core/database_api.php is vulnerable to variable poisoning attacks. By exploiting the vulnerability an attacker can connect to databases that are in the web server LAN. NOTE: This only works if the 'register_globals' directive is On. | |||||
| Additional Information | To reproduce the behavior simply navigate to any of these urls: http://bugs.mantisbt.org/core/database_api.php?g_db_type=mysql://invaliduser@localhost:3336 [^] http://bugs.mantisbt.org/core/database_api.php?g_db_type=mysql://root@localhost:3336 [^] http://bugs.mantisbt.org/core/database_api.php?g_db_type=informix://localhost:8080 [^] Due to this vulnerability you can write a database scanner or a network scanner by simply changing the hostname. Examples: 1.- http://bugs.mantisbt.org/core/database_api.php?g_db_type=mysql://root@localhost [^] (Fast response) 2.- http://bugs.mantisbt.org/core/database_api.php?g_db_type=mysql://root@localhost [^] (No response in about 30 seconds) 3.- //root@10.x.y.z">http://bugs.mantisbt.org/core/database_api.php?g_db_type=mysql://root@10.x.y.z [//root@10.x.y.z" target="_blank">^] (Response in 3 seconds) | |||||
| Tags | No tags attached. | |||||
| Attached Files |  0005956.patch [^] (502 bytes) 2005-07-18 10:40 [Show Content]
 poc.tar.gz [^] (1,596 bytes) 2005-07-18 16:04 modified.patch [^] (531 bytes) 2005-07-18 16:10 [Show Content]
| |||||
 Relationships |
|
 Relationships |
|
Notes |
|
 (0010820)joxeanpiti (reporter) 2005-07-16 19:41 |
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> [^] |
 (0010823)grangeway (developer) 2005-07-17 06:24 |
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 |
|
(0010829) joxeanpiti (reporter) 2005-07-17 13:21 edited on: 2005-07-17 13:22 |
> 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? |
|
(0010830) joxeanpiti (reporter) 2005-07-17 17:01 |
Verified. Version 1.43 of <mantis_dir>/core/database_api.php fixes the problem. |
 (0010838)vboctor (administrator) 2005-07-18 02:21 |
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. |
|
(0010846) joxeanpiti (reporter) 2005-07-18 09:17 |
>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). |
|
(0010855) joxeanpiti (reporter) 2005-07-18 10:41 edited on: 2005-07-18 13:23 |
I have been attached a patch that works for (any?) prior versions as well as the current of Mantis BT. |
|
(0010860) grangeway (developer) 2005-07-18 14:01 |
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 |
|
(0010863) joxeanpiti (reporter) 2005-07-18 16:06 edited on: 2005-07-18 16:11 |
> 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. |
 (0012087)thraxisp (manager) 2006-02-04 22:02 |
Fixed in CVS. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2005-07-16 19:34 | joxeanpiti | New Issue | |
| 2005-07-16 19:41 | joxeanpiti | Note Added: 0010820 | |
| 2005-07-16 19:42 | joxeanpiti | Issue Monitored: joxeanpiti | |
| 2005-07-17 06:12 | grangeway | Issue Monitored: vboctor | |
| 2005-07-17 06:12 | grangeway | Note Added: 0010822 | |
| 2005-07-17 06:24 | grangeway | Note Added: 0010823 | |
| 2005-07-17 06:24 | grangeway | Assigned To | => vboctor |
| 2005-07-17 06:24 | grangeway | Status | new => feedback |
| 2005-07-17 06:25 | grangeway | Note Deleted: 0010822 | |
| 2005-07-17 13:21 | joxeanpiti | Note Added: 0010829 | |
| 2005-07-17 13:22 | joxeanpiti | Note Edited: 0010829 | |
| 2005-07-17 17:01 | joxeanpiti | Note Added: 0010830 | |
| 2005-07-18 02:21 | vboctor | Note Added: 0010838 | |
| 2005-07-18 09:17 | joxeanpiti | Note Added: 0010846 | |
| 2005-07-18 10:40 | joxeanpiti | File Added: 0005956.patch | |
| 2005-07-18 10:41 | joxeanpiti | Note Added: 0010855 | |
| 2005-07-18 13:22 | joxeanpiti | Note Edited: 0010855 | |
| 2005-07-18 13:23 | joxeanpiti | Note Edited: 0010855 | |
| 2005-07-18 14:01 | grangeway | Note Added: 0010860 | |
| 2005-07-18 16:04 | joxeanpiti | File Added: poc.tar.gz | |
| 2005-07-18 16:06 | joxeanpiti | Note Added: 0010863 | |
| 2005-07-18 16:07 | joxeanpiti | Note Edited: 0010863 | |
| 2005-07-18 16:10 | joxeanpiti | File Added: modified.patch | |
| 2005-07-18 16:11 | joxeanpiti | Note Edited: 0010863 | |
| 2006-02-04 22:02 | thraxisp | Status | feedback => resolved |
| 2006-02-04 22:02 | thraxisp | Fixed in Version | => 1.0.0rc1 |
| 2006-02-04 22:02 | thraxisp | Resolution | open => fixed |
| 2006-02-04 22:02 | thraxisp | Note Added: 0012087 | |
| 2006-02-04 22:03 | thraxisp | Status | resolved => closed |
| 2006-10-09 11:55 | thraxisp | View Status | private => public |
|
Issue History |
| MantisBT 1.2.0rc2 git live[^]
Copyright © 2000 - 2010 MantisBT Group
Time: 0.3480 seconds. memory usage: 1,859 KB |
 |