View Issue Details

IDProjectCategoryView StatusLast Update
0024221mantisbtsecuritypublic2018-04-29 19:21
Reporterstrukt Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0 
Target Version2.13.2Fixed in Version2.13.2 
Summary0024221: CVE-2018-9839: Private issues accessible to unauthorized users using the "Clone" functionality
Description

When a user that doesn't have access to an issue because its View Status is set to "private" attempts to clone an issue, a POST request like the following is sent:

POST /mantisbt-2.13.0/bug_report_page.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://localhost/mantisbt-2.13.0/view.php?id=8
Content-Type: application/x-www-form-urlencoded
Cookie: [redacted]

bug_report_page_token=201804042OfH9dLS3pONvK2XHmGLwrMJfrYjHyGz&m_id=8

The issue is that, if the user changes the "m_id" value to that of any of the private issues, they will be able to see all the information belonging to the targeted issue.

Steps To Reproduce

1- Create an issue with the "administrator" account or similar, set it's View Status to "private".
2- Using a "Reporter" account, try to access the issue directly, notice the "Access Denied" error.
3- Using a "Reporter" account, attempt to clone an issue of that account's ownership.
4- Repeat with replacing the "m_id" of the issue to that of the private issue, observe accessibility to the issue information.

Additional Information

Please request a CVE for the reported bug once fixed, details:

Name: Mustafa Hasan (strukt)
Email: strukt93@gmail.com
Company: N/A

TagsNo tags attached.
Attached Files

Relationships

has duplicate 0024365 closeddregad CVE-2018-9839: Private issues accessible to unauthorized users using the "Clone" functionality 

Activities

dregad

dregad

2018-04-04 11:39

developer   ~0059429

Last edited: 2018-04-04 11:48

Thanks for the bug report. I can confirm the behavior. Problem is also present in 1.3.x branch (tested in 1.3.0 and 1.3.14).

dregad

dregad

2018-04-06 11:27

developer   ~0059452

CVE Request 489002 sent to MITRE.

Proposed fix: add an access level check, so that the operation now fails with an Access Denied error. Kindly test attached patch and confirm it does resolve the problem.

0001-Prevent-cloning-private-issues-by-unauthorized-users.patch (1,401 bytes)   
From bd6bf9c2df3d1d69f653214e8916fec15a2eb6ef Mon Sep 17 00:00:00 2001
From: Damien Regad <dregad@mantisbt.org>
Date: Fri, 6 Apr 2018 16:50:26 +0200
Subject: [PATCH] Prevent cloning private issues by unauthorized users

Using a crafted request on bug_report_page.php (modifying the 'm_id'
parameter), any user with REPORTER access or above is able to view any
private issue's details (summary, description, steps to reproduce,
additional information) when cloning. By checking the 'Copy issue notes'
and 'Copy attachments' checkboxes and completing the clone operation,
this data also becomes public (except private notes).

Added an access level check, so that the operation now fails with an
Access Denied error.

Credits to Mustafa Hasan (strukt) strukt93@gmail.com for the finding.

Fixes #24221
---
 bug_report_page.php | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bug_report_page.php b/bug_report_page.php
index 2fc3f0a..79a35df 100644
--- a/bug_report_page.php
+++ b/bug_report_page.php
@@ -89,6 +89,9 @@ if( $f_master_bug_id > 0 ) {
 		trigger_error( ERROR_BUG_READ_ONLY_ACTION_DENIED, ERROR );
 	}
 
+	# User can view the master bug
+	access_ensure_bug_level( config_get( 'view_bug_threshold' ), $f_master_bug_id );
+
 	$t_bug = bug_get( $f_master_bug_id, true );
 
 	#@@@ (thraxisp) Note that the master bug is cloned into the same project as the master, independent of
-- 
1.9.1

dregad

dregad

2018-04-08 05:16

developer   ~0059456

CVE-2018-9839 assigned

strukt

strukt

2018-04-09 17:26

reporter   ~0059502

Thank you very much

dregad

dregad

2018-04-10 03:08

developer   ~0059508

@strukt please note that this is not public yet. We usually disclose when the patch goes live with the next release. This might be delayed a bit as vboctor is currently traveling, and we have a couple other issues that need urgent fixing.

In the meanwhile I would appreciate if you could confirm that the proposed patch does fix the problem.

atrol

atrol

2018-04-10 16:26

developer   ~0059520

Last edited: 2018-04-10 16:26

Didn't have a deeper look.
Do we need the same check in bug_report.php before calling bug_get ?

strukt

strukt

2018-04-11 09:03

reporter   ~0059527

Sure, nothing would be disclosed until you do so. As for the patch, I will try to test it in the coming days since I am quite busy with other matters. Thank you very much all.

vboctor

vboctor

2018-04-14 14:24

manager   ~0059568

@strukt good catch

@dregad

  • Unrelated: It is unclear to me why why we require the master bug to be read-only before cloning it.
  • If for some reason the read-only access is necessary, should we have the access check before it?
atrol

atrol

2018-04-14 14:44

developer   ~0059569

Unrelated: It is unclear to me why why we require the master bug to be read-only before cloning it.

Assume you mean NOT read-only
Maybe because we offer to create relationships with the master bug.

vboctor

vboctor

2018-04-14 15:27

manager   ~0059570

Assume you mean NOT read-only
Maybe because we offer to create relationships with the master bug.

You are right about NOT read-only, that is what I meant. But I think it should be OK to clone an issue even if it is read-only. Whether we add relationship for read-only source issues or not is debate-able.

strukt

strukt

2018-04-14 18:09

reporter   ~0059572

@vboctor thank you :-), good luck with the fix.

dregad

dregad

2018-04-25 12:18

developer   ~0059686

Last edited: 2018-04-25 12:19

Sorry it took me so long to get back to this.

Do we need the same check in bug_report.php before calling bug_get ?

I just tested, and while using a forged request [1] to call bug_report.php directly does not let the user see the private issue's data itself, it still allows them to copy the bugnotes and attachments, so the vulnerability does need to be patched there as well.

Related Changesets

MantisBT: master 1fbcd9bc

2018-04-25 08:31

dregad


Details Diff
Prevent cloning private issues by unauthorized users

Using a crafted request on bug_report_page.php (modifying the 'm_id'
parameter), any user with REPORTER access or above is able to view any
private issue's details (summary, description, steps to reproduce,
additional information) when cloning. By checking the 'Copy issue notes'
and 'Copy attachments' checkboxes and completing the clone operation,
this data also becomes public (except private notes).

Credits to Mustafa Hasan (strukt) strukt93@gmail.com for the finding.

@atrol noted that the same vulnerability also existed in bug_report.php,
although in this case the information disclosure is limited to notes and
attachments (issue data itself does not become accessible).

Added an access level check, so that the operation now fails with an
Access Denied error in both cases.

Fixes 0024221, CVE-2018-9839
Prevent cloning private issues by unauthorized users

Using a crafted request on bug_report_page.php (modifying the 'm_id'
parameter), any user with REPORTER access or above is able to view any
private issue's details (summary, description, steps to reproduce,
additional information) when cloning. By checking the 'Copy issue notes'
and 'Copy attachments' checkboxes and completing the clone operation,
this data also becomes public (except private notes).

Added an access level check, so that the operation now fails with an
Access Denied error.

Credits to Mustafa Hasan (strukt) strukt93@gmail.com for the finding.

Fixes 0024221
Affected Issues
0024221
mod - bug_report.php Diff File
mod - bug_report_page.php Diff File