| Anonymous | Login | Signup for a new account | 2013-05-24 19:33 EDT |  |
| Main | My View | View Issues | Change Log | Roadmap | Wiki | ManTweet | Repositories |
| View Issue Details [ Jump to Notes ] [ Wiki ] [ Related Changesets ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0010124 | mantisbt | security | public | 2009-02-10 07:25 | 2013-04-06 09:24 | ||||
| Reporter | empty | ||||||||
| Assigned To | dregad | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 1.2.8 | ||||||||
| Target Version | 1.2.9 | Fixed in Version | 1.2.9 | ||||||
| Summary | 0010124: Bug in access_has_bug_level | ||||||||
| Description | There's a heavy problem in the access_has_bug_level function giving access to everyone. By setting the private_bug_view_threshold via the project configuration to an array (and not only a number) eg. if you have 0 0 X 0 X X in the configuration, this will result in an Array, instead of 0 0 X X X X resulting in a number in the mantis_config_table. This leads to a misfunction in access_api.php/function access_has_bug_level: The code there: # If the bug is private and the user is not the reporter, then the # the user must also have higher access than private_bug_threshold if ( VS_PRIVATE == bug_get_field( $p_bug_id, 'view_state' ) && !bug_is_user_reporter( $p_bug_id, $p_user_id ) ) { $p_access_level = max( $p_access_level, config_get( 'private_bug_threshold' ) ); } So, the parameter of the max-Funktion are an access_level, e.g. MANAGER and an array with the private_bug_threshold from the database. The result: Because the max-Function can't handle this integer/array-mixture, the returned value is empty, so everyone has access to the bug. | ||||||||
| Steps To Reproduce | see above. | ||||||||
| Tags | 2.0.x check | ||||||||
| Attached Files | |||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
 (0031005)Zonix (reporter) 2012-01-23 08:08 |
Just stumbled on this as well in 1.2.8: We have a strong policy that nobody should be allowed to delete issues, thus I set delete_bug_threshold = NOBODY. Private bugs are accessible for certain roles only, so I configured private_bug_threshold = array ( 0 => 40, 1 => 42, 2 => 55, 3 => 60, 4 => 65, 5 => 90, ) with the configuration pages. The result is that anyone can actually delete private bugs (delete button on bug view page). I consider this a major bug since the security scheme for private bugs can be accidently broken by an administrator who configures the private_bug_threshold individually for access roles. Could anyone take care of this issue? BTW, category "authentication" should be changed to "security" since this problem is not only related to authentication. |
 (0031008)dregad (developer) 2012-01-23 14:19 |
I believed I fixed it, please see https://github.com/dregad/mantisbt/tree/fix-10124-access_has_bug_level [^] Could you kindly test and let me know if it works. |
|
(0031011) Zonix (reporter) 2012-01-24 03:04 |
Hi dregard, thanks for the quick fix. I can confirm that your patch fixes the issue. |
|
(0031012) dregad (developer) 2012-01-24 05:24 |
Thanks for testing. As this is a very widely used function, I have asked other devs to have a look at it before I commit the change, to make sure this is not introducing any regression. |
 (0031392)dhx (developer) 2012-03-06 17:33 edited on: 2012-03-06 17:33 |
A CVE identifier has been assigned to this issue: CVE-2012-1118 MantisBT 1.2.8 10124 array value for $g_private_bug_threshold configuration option allows bypass of access checks |
 (0036310)grangeway (developer) 2013-04-05 17:57 |
Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch |
|
Notes |
| Related Changesets |
|||
|
MantisBT: master eb803ed0
Timestamp: 2012-01-23 11:01:59 Author: dregad [ Details ] [ Diff ] |
Fix bug in access_has_bug_level() for private issues When private_bug_threshold is defined as an array instead of a single access level, e.g. array(0=>40, 1=>70, 2=>90) to prevent developers from seeing private bugs while granting that privilege to updaters, access_has_bug_level() incorrectly returned true. The consequence is that unwanted access to Private bugs was granted to users who are allowed to view them, e.g. allowing them to delete or perform other restricted actions. Fixes 0010124 |
||
| mod - core/access_api.php | [ Diff ] [ File ] | ||
|
MantisBT: master-1.2.x ae8be028
Timestamp: 2012-01-23 11:01:59 Author: dregad [ Details ] [ Diff ] |
Fix bug in access_has_bug_level() for private issues When private_bug_threshold is defined as an array instead of a single access level, e.g. array(0=>40, 1=>70, 2=>90) to prevent developers from seeing private bugs while granting that privilege to updaters, access_has_bug_level() incorrectly returned true. The consequence is that unwanted access to Private bugs was granted to users who are allowed to view them, e.g. allowing them to delete or perform other restricted actions. Fixes 0010124 |
||
| mod - core/access_api.php | [ Diff ] [ File ] | ||
| Related Changesets |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-02-10 07:25 | empty | New Issue | |
| 2012-01-23 08:08 | Zonix | Note Added: 0031005 | |
| 2012-01-23 08:57 | dregad | Status | new => confirmed |
| 2012-01-23 08:57 | dregad | Category | authentication => security |
| 2012-01-23 08:57 | dregad | Product Version | 1.1.6 => 1.2.8 |
| 2012-01-23 14:19 | dregad | Note Added: 0031008 | |
| 2012-01-23 14:19 | dregad | Assigned To | => dregad |
| 2012-01-23 14:19 | dregad | Status | confirmed => assigned |
| 2012-01-23 14:19 | dregad | Target Version | => 1.2.9 |
| 2012-01-24 03:04 | Zonix | Note Added: 0031011 | |
| 2012-01-24 05:24 | dregad | Note Added: 0031012 | |
| 2012-02-27 19:45 | dregad | Status | assigned => resolved |
| 2012-02-27 19:45 | dregad | Fixed in Version | => 1.2.9 |
| 2012-02-27 19:45 | dregad | Resolution | open => fixed |
| 2012-02-27 20:00 | dregad | Changeset attached | => MantisBT master eb803ed0 |
| 2012-02-27 20:00 | dregad | Changeset attached | => MantisBT master-1.2.x ae8be028 |
| 2012-03-03 21:45 | vboctor | Status | resolved => closed |
| 2012-03-06 17:33 | dhx | Note Added: 0031392 | |
| 2012-03-06 17:33 | dhx | Note Edited: 0031392 | View Revisions |
| 2013-04-05 17:57 | grangeway | Status | closed => acknowledged |
| 2013-04-05 17:57 | grangeway | Note Added: 0036310 | |
| 2013-04-05 18:25 | grangeway | Relationship added | related to 0015721 |
| 2013-04-06 03:42 | dregad | Status | acknowledged => closed |
| 2013-04-06 07:23 | grangeway | Status | closed => acknowledged |
| 2013-04-06 09:24 | dregad | Tag Attached: 2.0.x check | |
| 2013-04-06 09:24 | dregad | Status | acknowledged => closed |
|
Issue History |
| MantisBT 1.2.16dev master-1.2.x-8c2bd07 [^]
Copyright © 2000 - 2013 MantisBT Team
Time: 0.1123 seconds. memory usage: 2,842 KB |
|