View Issue Details

IDProjectCategoryView StatusLast Update
0014340mantisbtsecuritypublic2014-09-23 18:05
Reporteratrol 
Assigned Todhx 
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
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
Description

Reporters 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.

Relationships

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

Activities

dhx

dhx

2012-06-02 03:51

reporter   ~0031974

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.

dregad

dregad

2012-06-03 12:12

developer   ~0031993

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

dregad

dregad

2012-06-03 18:04

developer   ~0031995

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.

dregad

dregad

2012-06-03 18:55

developer   ~0031996

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.

dhx

dhx

2012-06-09 06:00

reporter   ~0032048

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

dhx

dhx

2012-06-12 04:46

reporter   ~0032076

CVE-2012-2691

grangeway

grangeway

2013-04-05 17:56

reporter   ~0036084

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

Related Changesets

MantisBT: master 508cab00

2012-06-02 00:40:10

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

2012-06-02 00:40:10

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

2012-06-03 15:29:44

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

2012-06-03 15:29:44

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

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