MantisBT

View Issue Details Jump to Notes ] Wiki ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014016mantisbtsecuritypublic2012-03-07 16:592013-04-06 09:23
Reporteratrol 
Assigned Toatrol 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.2.9 
Target Version1.2.11Fixed in Version1.2.11 
Summary0014016: CVE-2012-2692 Users with access level >= update_bug_threshold can delete any attachment
DescriptionIn a default installation delete_attachments_threshold is set to DEVELOPER but having access level >= update_bug_threshold is enough to delete attachments if
form_security_validation is set to OFF;

The issue should be fixed along with related issue 0014015
As long as the related issue is not fixed, you have to set update_bug_threshold = REPORTER to get no issues when setting allow_delete_own_attachments = ON
But this means that even reporters might be able to remove attachments of other users.

If allow_delete_own_attachments is set to ON you will not get the link to delete the attachments of other users,
but there is no code which prevents the deletion when using the link via browser.
Steps To ReproduceSet $g_form_security_validation = OFF;
Create private project P1
Create user DEV with access level DEVELOPER for project P1
Create user UPD with access level UPDATER for project P1
Login as DEV and report an issue # 1 for project P1 with attachment
Login as UPD and add another attachment to issue # 1

Hover over the attachments to see the file_id's of attachments
Enter in your browser http://<MantisRoot>/bug_file_delete.php?file_id=<IdOfAnyAttachment> [^]
Tags2.0.x check
Attached Files

- Relationships
related to 0014015closeddhx Users with access level REPORTER cannot delete own attachments despite allow_delete_own_attachments = ON; 
related to 0015721closedgrangeway Functionality to consider porting to master-2.0.x 

-  Notes
User avatar (0031978)
dhx (developer)
2012-06-02 07:26

Thanks for the perfect bug report Roland!

I have applied a patch (ceafe6f) for this embarrassing problem in master-1.2.x and master.
User avatar (0031990)
atrol (developer)
2012-06-03 07:44
edited on: 2012-06-03 07:47

The following line in function mc_issue_attachment_delete is wrong

$t_attachment_owner = file_get_field( $f_file_id, 'user_id' );

$f_file_id is not defined at this place.
Should be $p_issue_attachment_id

I will provide a fix for it.

User avatar (0032049)
dhx (developer)
2012-06-09 06:00
edited on: 2012-06-09 07:49

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 (0032077)
dhx (developer)
2012-06-12 04:46

CVE-2012-2692
User avatar (0036083)
grangeway (developer)
2013-04-05 17:56

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

- Related Changesets
MantisBT: master f82f98cc
Timestamp: 2012-06-02 04:10:32
Author: dhx
Details ] Diff ]
Fix 0014016: delete_attachments_threshold is not checked

Roland Becker (MantisBT developer) reported the following
security/access control bug:

In a default installation delete_attachments_threshold is set to
DEVELOPER but having access level >= update_bug_threshold is enough to
delete attachments if form_security_validation is set to OFF.

MantisBT was not checking the access level of the user requesting
deletion of an attachment to an issue against
$g_delete_attachments_threshold.

The new access control logic for deleting an issue attachment is now:
1. Does the user have an access level of at least update_bug_threshold?
2. If the user is the owner of the file and
$g_allow_delete_own_attachments=OFF, does this user have an access level
of at least delete_attachments_threshold?
3. If the user is not the owner of the file, do they have an access
level of at least delete_attachments_threshold?

Also refer to issue 0014015 for discussion on whether
update_bug_threshold should be part of the access control logic.

The relevant SOAP API call has also been updated.

Conflicts:
    bug_file_delete.php
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]
mod - bug_file_delete.php Diff ] File ]
MantisBT: master-1.2.x ceafe6f0
Timestamp: 2012-06-02 04:10:32
Author: dhx
Details ] Diff ]
Fix 0014016: delete_attachments_threshold is not checked

Roland Becker (MantisBT developer) reported the following
security/access control bug:

In a default installation delete_attachments_threshold is set to
DEVELOPER but having access level >= update_bug_threshold is enough to
delete attachments if form_security_validation is set to OFF.

MantisBT was not checking the access level of the user requesting
deletion of an attachment to an issue against
$g_delete_attachments_threshold.

The new access control logic for deleting an issue attachment is now:
1. Does the user have an access level of at least update_bug_threshold?
2. If the user is the owner of the file and
$g_allow_delete_own_attachments=OFF, does this user have an access level
of at least delete_attachments_threshold?
3. If the user is not the owner of the file, do they have an access
level of at least delete_attachments_threshold?

Also refer to issue 0014015 for discussion on whether
update_bug_threshold should be part of the access control logic.

The relevant SOAP API call has also been updated.
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]
mod - bug_file_delete.php Diff ] File ]
MantisBT: master 31d11568
Timestamp: 2012-06-02 04:35:19
Author: dhx
Details ] Diff ]
Fix 0014015: attachment deletion: remove update_bug_threshold check

As reported by Roland Becker (MantisBT developer):

Although configuration option allow_delete_own_attachments is set to ON
reporters cannot delete their own attachments. After pushing the delete
button you get "Access Denied"

Issue 0014016 implemented correct attachment deletion access control
checks against delete_attachments_threshold. We should be using this
threshold instead of update_bug_threshold because attachments aren't
linked to the core fields of an issue -- they are frequently related to
comments (bugnotes) provided by less privileged users.

$g_allow_delete_own_attachments should now work again... safely.
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]
mod - bug_file_delete.php Diff ] File ]
MantisBT: master-1.2.x 628e9370
Timestamp: 2012-06-02 04:35:19
Author: dhx
Details ] Diff ]
Fix 0014015: attachment deletion: remove update_bug_threshold check

As reported by Roland Becker (MantisBT developer):

Although configuration option allow_delete_own_attachments is set to ON
reporters cannot delete their own attachments. After pushing the delete
button you get "Access Denied"

Issue 0014016 implemented correct attachment deletion access control
checks against delete_attachments_threshold. We should be using this
threshold instead of update_bug_threshold because attachments aren't
linked to the core fields of an issue -- they are frequently related to
comments (bugnotes) provided by less privileged users.

$g_allow_delete_own_attachments should now work again... safely.

Conflicts:
    bug_file_delete.php
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]
mod - bug_file_delete.php Diff ] File ]
MantisBT: master-1.2.x c9314184
Timestamp: 2012-06-03 04:51:08
Author: atrol
Details ] Diff ]
Additional patch to fix 0014016

First patch to fix the issue introduced access to undefined variable.
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]
MantisBT: master 75568c53
Timestamp: 2012-06-03 04:53:41
Author: atrol
Details ] Diff ]
Additional patch to fix 0014016

First patch to fix the issue introduced access to undefined variable.
mod - api/soap/mc_issue_attachment_api.php Diff ] File ]

- Issue History
Date Modified Username Field Change
2012-03-07 16:59 atrol New Issue
2012-03-07 16:59 atrol Relationship added related to 0014015
2012-03-07 17:02 atrol Description Updated View Revisions
2012-04-02 02:33 atrol Target Version 1.2.10 => 1.2.11
2012-06-02 06:44 dhx Assigned To => dhx
2012-06-02 06:44 dhx Status new => assigned
2012-06-02 07:26 dhx Note Added: 0031978
2012-06-02 07:26 dhx Status assigned => resolved
2012-06-02 07:26 dhx Fixed in Version => 1.2.11
2012-06-02 07:26 dhx Resolution open => fixed
2012-06-02 07:27 dhx View Status private => public
2012-06-02 08:00 dhx Changeset attached => MantisBT master 31d11568
2012-06-02 08:00 dhx Changeset attached => MantisBT master f82f98cc
2012-06-02 08:00 dhx Changeset attached => MantisBT master-1.2.x 628e9370
2012-06-02 08:00 dhx Changeset attached => MantisBT master-1.2.x ceafe6f0
2012-06-03 07:44 atrol Note Added: 0031990
2012-06-03 07:44 atrol Status resolved => feedback
2012-06-03 07:44 atrol Resolution fixed => reopened
2012-06-03 07:47 atrol Assigned To dhx => atrol
2012-06-03 07:47 atrol Status feedback => assigned
2012-06-03 07:47 atrol Note Edited: 0031990 View Revisions
2012-06-03 09:00 atrol Changeset attached => MantisBT master 75568c53
2012-06-03 09:00 atrol Changeset attached => MantisBT master-1.2.x c9314184
2012-06-03 09:00 atrol Status assigned => resolved
2012-06-06 23:53 jreese Status resolved => closed
2012-06-09 06:00 dhx Note Added: 0032049
2012-06-09 07:49 dhx Note Edited: 0032049 View Revisions
2012-06-12 04:46 dhx Note Added: 0032077
2012-08-22 18:11 atrol Resolution reopened => fixed
2013-03-04 11:19 dregad Summary Users with access level >= update_bug_threshold can delete any attachment => CVE-2012-2692 Users with access level >= update_bug_threshold can delete any attachment
2013-04-05 17:56 grangeway Status closed => acknowledged
2013-04-05 17:56 grangeway Note Added: 0036083
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


MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.1035 seconds.
memory usage: 3,130 KB
Powered by Mantis Bugtracker