2014-12-21 13:39 EST

View Issue Details Jump to Notes ] Wiki ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0014340mantisbtsecuritypublic2014-09-23 18:05
Reporteratrol 
Assigned Todhx 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Product Version1.2.10 
Target Version1.2.11Fixed in Version1.2.11 
Summary0014340: CVE-2012-2691 Reporters can update notes of other users by using SOAP API
DescriptionReporters are not able to update notes of other users in a standard MantisBT configuration when using the web interface.
This is the intended behaviour as the default setting for the access check is $g_update_bugnote_threshold = DEVELOPER;

However the access check when using the SOAP API (function mc_issue_note_update) uses option $g_add_bugnote_threshold which defaults to REPORTER.
This means that any reporter is able to remove the contents of all bugnotes!

Replacing $g_add_bugnote_threshold by $g_update_bugnote_threshold is not enough to solve the issue, as reporters will not be able to update their own notes.
Checking that the id of the current user is the same id like the reporter id of the note is no clean solution, but acceptable and already used in source code at various places. (function access_has_bugnote_level, bugnote_edit_page.php, …)

Example where this approach is no clean solution:
User A (REPORTER) enters issue 1 with note 1
User A get's restricted to be a VIEWER
Current implementation will still allow User A to edit note 1 because there are places in source code where access checking is only executed if current_user_id != bugnote_reporter_id

Quick solution:
Add checks to function mc_issue_note_update

Clean solution:
Implement a helper function which returns true or false to check access rights.
Use the function in SOAP and Web code
TagsNo tags attached.
Attached Files

- Relationships
related to 0015721closedgrangeway Functionality to consider porting to master-2.0.x 
+ Relationships

-  Notes
User avatar

~0031974

dhx (reporter)

This should now be fixed in master and master-1.2.x however I haven't tested the code (I don't use SOAP).

Can someone please double check and confirm my patch is valid and functional?

Thanks again Roland, Damien (sorry for the typo in the commit message!) for finding and reporting this issue.
User avatar

~0031993

dregad (developer)

Thanks for the fix David and no worries about the typo - it happens all the time ;)
User avatar

~0031995

dregad (developer)

I did a quick check on my local dev box - problem is not fixed yet.

created a test user (reporter)
created a test issue
as another user, added a note to the issue
then execute following code
<?php
    $c = new SoapClient("http://localhost/mantis/api/soap/mantisconnect.php?wsdl" [^]);
    $u = 'soaprep';
    $p = 'soap';
    $n = array( 'id' => 33, 'text' => "SOAP edit someone else's note " . time() );
    $c->mc_issue_note_update($u, $p, $n);


... and the note 33 was updated.
User avatar

~0031996

dregad (developer)

Found the root cause - mc_issue_note_update was passing wrong parameters to access_has_bugnote_level() so unprivileged users could still update other's bugnotes.
User avatar

~0032048

dhx (reporter)

Last edited: 2012-06-09 07:50

View 2 revisions

http://www.openwall.com/lists/oss-security/2012/06/09/1 [^]

https://bugs.gentoo.org/show_bug.cgi?id=420375 [^]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676783 [^]

User avatar

~0032076

dhx (reporter)

CVE-2012-2691
User avatar

~0036084

grangeway (reporter)

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch
+  Notes

- Related Changesets
MantisBT: master 508cab00
Timestamp: 2012-06-02 00:40:10
Author: dhx
Details ] Diff ]
Fix 0014340: Reporters can use SOAP to update bugnotes without permission

The access checks inside bugnote_update.php and
api/soap/mc_issue_api.php differed. Users were incorrectly allowed via
the SOAP interface to update the bugnotes of other users. Instead of
comparing the SOAP user's access level to $g_update_bugnote_threshold,
$g_add_bugnote_threshold was used instead.

This posed a problem because the default installed state of MantisBT is
to allow the REPORTER access level to submit bugs via the SOAP API. Thus
in the default installed state, any user who could submit a bug could
also update/modify the bugnotes of any other user.

Access checks within bugnote_update.php and api/soap/mc_issue_api.php
should now be equivalent.

Thanks to Roland Becker and Damien Regard (both MantisBT developers) for
finding and reporting this problem.
mod - api/soap/mc_issue_api.php Diff ] File ]
MantisBT: master-1.2.x edc8142b
Timestamp: 2012-06-02 00:40:10
Author: dhx
Details ] Diff ]
Fix 0014340: Reporters can use SOAP to update bugnotes without permission

The access checks inside bugnote_update.php and
api/soap/mc_issue_api.php differed. Users were incorrectly allowed via
the SOAP interface to update the bugnotes of other users. Instead of
comparing the SOAP user's access level to $g_update_bugnote_threshold,
$g_add_bugnote_threshold was used instead.

This posed a problem because the default installed state of MantisBT is
to allow the REPORTER access level to submit bugs via the SOAP API. Thus
in the default installed state, any user who could submit a bug could
also update/modify the bugnotes of any other user.

Access checks within bugnote_update.php and api/soap/mc_issue_api.php
should now be equivalent.

Thanks to Roland Becker and Damien Regard (both MantisBT developers) for
finding and reporting this problem.
mod - api/soap/mc_issue_api.php Diff ] File ]
MantisBT: master 15a5d6a3
Timestamp: 2012-06-03 15:29:44
Author: dregad
Details ] Diff ]
mc_issue_note_update passing wrong param to access check function

Commit edc8142bb8ac0ac0df1a3824d78c15f4015d959e introduced proper logic
to avoid unauthorized update of bugnotes, but was passing incorrect
parameters to access_has_bugnote_level() so unprivileged users could
still update them.

Fixes 0014340
mod - api/soap/mc_issue_api.php Diff ] File ]
MantisBT: master-1.2.x 175d9731
Timestamp: 2012-06-03 15:29:44
Author: dregad
Details ] Diff ]
mc_issue_note_update passing wrong param to access check function

Commit edc8142bb8ac0ac0df1a3824d78c15f4015d959e introduced proper logic
to avoid unauthorized update of bugnotes, but was passing incorrect
parameters to access_has_bugnote_level() so unprivileged users could
still update them.

Fixes 0014340
mod - api/soap/mc_issue_api.php Diff ] File ]

+ Related Changesets

- Issue History
Date Modified Username Field Change
2012-06-01 17:19 atrol New Issue
2012-06-02 03:48 dhx Assigned To => dhx
2012-06-02 03:48 dhx Status new => assigned
2012-06-02 03:49 dhx Status assigned => resolved
2012-06-02 03:49 dhx Fixed in Version => 1.2.11
2012-06-02 03:49 dhx Resolution open => fixed
2012-06-02 03:49 dhx View Status private => public
2012-06-02 03:51 dhx Note Added: 0031974
2012-06-02 04:00 dhx Changeset attached => MantisBT master 508cab00
2012-06-02 04:00 dhx Changeset attached => MantisBT master-1.2.x edc8142b
2012-06-03 12:12 dregad Note Added: 0031993
2012-06-03 18:04 dregad Note Added: 0031995
2012-06-03 18:04 dregad Status resolved => feedback
2012-06-03 18:04 dregad Resolution fixed => reopened
2012-06-03 18:05 dregad View Status public => private
2012-06-03 18:55 dregad Note Added: 0031996
2012-06-03 18:55 dregad Status feedback => resolved
2012-06-03 18:55 dregad Resolution reopened => fixed
2012-06-03 18:56 dregad View Status private => public
2012-06-03 19:00 dregad Changeset attached => MantisBT master 15a5d6a3
2012-06-03 19:00 dregad Changeset attached => MantisBT master-1.2.x 175d9731
2012-06-06 23:53 jreese Status resolved => closed
2012-06-09 06:00 dhx Note Added: 0032048
2012-06-09 07:50 dhx Note Edited: 0032048 View Revisions
2012-06-12 04:46 dhx Note Added: 0032076
2013-03-04 11:19 dregad Summary Reporters can update notes of other users by using SOAP API => CVE-2012-2691 Reporters can update notes of other users by using SOAP API
2013-04-05 17:56 grangeway Status closed => acknowledged
2013-04-05 17:56 grangeway Note Added: 0036084
2013-04-05 19:41 grangeway Relationship added related to 0015721
2013-04-06 03:40 dregad Status acknowledged => closed
2013-04-06 07:23 grangeway Status closed => acknowledged
2013-04-06 09:22 dregad Tag Attached: 2.0.x check
2013-04-06 09:23 dregad Status acknowledged => closed
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check
+ Issue History