View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0024221 | mantisbt | security | public | 2018-04-04 07:52 | 2018-04-29 19:21 |
Reporter | strukt | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0 | ||||
Target Version | 2.13.2 | Fixed in Version | 2.13.2 | ||
Summary | 0024221: 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 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". | ||||
Additional Information | Please request a CVE for the reported bug once fixed, details: Name: Mustafa Hasan (strukt) | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
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). |
|
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 |
|
CVE-2018-9839 assigned |
|
Thank you very much |
|
@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. |
|
Didn't have a deeper look. |
|
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. |
|
@strukt good catch
|
|
Assume you mean |
|
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. |
|
@vboctor thank you :-), good luck with the fix. |
|
Sorry it took me so long to get back to this.
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. |
|
MantisBT: master 1fbcd9bc 2018-04-25 08:31 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 |