Date: Tue, 06 Mar 2012 23:53:20 +1000 From: David Hicks <d@...id.au> To: oss-security@...ts.openwall.com Subject: Re: CVE request: mantisbt before 1.2.9 Thanks Hanno and apologies on behalf of the MantisBT project for the lack of official notice. I'll attempt to provide as much detail on the security issue(s) resolved in MantisBT 1.2.9 noting that I haven't had much involvement with this release over the past few months. The mantisbt-dev@...ts.sourceforge.net mailing list has been BCC'd to this email. I have made public the relevant security issues reported on http://www.mantisbt.org/bugs that have been fixed in MantisBT 1.2.9. These previously hidden issues will now show up in the change log for version 1.2.9. There are a number of CVE requests that should have been made a while ago (#6 which is particularly nasty). CVE REQUEST #1: MantisBT < 1.2.9 array value for $g_private_bug_threshold configuration option allows bypass of access checks http://www.mantisbt.org/bugs/view.php?id=10124 A rarely known feature of MantisBT is the ability to define access thresholds as an array of "allowed access groups" rather than just an integer value (for a linear scale of increasing access levels). If the $g_private_bug_threshold value was defined as an array, all access checks within MantisBT would by bypassed/allowed. This is a low risk issue because it would be very obvious to administrators that permissions were broken (they'd notice that anonymous users can access every feature). [NOTE: this feature is so rarely known that large chunks of the MantisBT code base are written under the assumption that thresholds are always integer values. In the great majority of cases a threshold with an array value will fail safely because array() == x where x is an integer will return false. This bug is particularly nasty because it was within the main access check function MantisBT uses throughout the code base. From a user perspective, defining thresholds using an array is _NOT_ recommended until a full audit of the code base is performed to ensure that it is safe to define thresholds using array values.] CVE REQUEST #2: MantisBT < 1.2.9 copy/clone bug report action failed to leave an audit trail http://www.mantisbt.org/bugs/view.php?id=13816 The copy/clone bug feature could be misused by authorised users to spam an issue tracker with multiple copies of bugs with no obvious audit trail of who was responsible. This is an annoyance on par with new users signing up to a bug tracker and generating bugnote (or other) spam. There is only so much we can do to solve the problem -- it is mostly up to the administrator of each MantisBT installation to screen new users. CVE REQUEST #3: MantisBT < 1.2.9 delete_bug_threshold/bugnote_allow_user_edit_delete access check bypass via SOAP API http://www.mantisbt.org/bugs/view.php?id=13656 Users with write access to the SOAP API (this is a separate access check) were able to delete issues and bugnotes regardless of the configured $g_delete_bug_threshold and $g_bugnote_allow_user_edit_delete settings. As users need to be authorised and have read/write access via SOAP, they're likely already trusted. Additionally, SOAP is a feature that is rarely used on Internet facing bug trackers. For these reasons the impact of this bug is significantly reduced. CVE REQUEST #4: MantisBT < 1.2.9 managers of specific projects could update global category settings http://www.mantisbt.org/bugs/view.php?id=13561 If a user was given 'manager' permissions over a single project, they were also incorrectly allowed to modify and delete global bug categories. Consequences of this bug are limited because 'manager' permissions are usually reserved for trusted users and aren't handed out lightly. CVE REQUEST #5: MantisBT < 1.2.9 incorrect access checks performed when moving bugs between projects http://www.mantisbt.org/bugs/view.php?id=13748 When a user attempted to move a bug between projects, an invalid access check was performed. The $g_report_bug_threshold access level from the source project was used instead of the $g_report_bug_threshold access level from the destination project. The result of this bug is that users could move bugs into projects that they did not have access to report bugs within. CVE REQUEST #6: MantisBT < 1.2.9 SOAP API null password authentication bypass http://www.mantisbt.org/bugs/view.php?id=13901 This serious issue allowed an an attacker to bypass SOAP API authentication and login as any user without needing to provide a valid password. A SOAP client sending a null password field could assume the identity of a MantisBT administrator without needing a password and gain full access to the SOAP API (and consequently the entire MantisBT installation). [NOTE: the above summary for request #4 is based on reports made to the mantisbt-dev mailing list on the 16th of February 2012 - I have not independently confirmed the validity of this report. It may be worth waiting for independent confirmation of this report via mantisbt-dev. If this issue is valid, it has already been fixed in MantisBT 1.2.9 "just in case" by disallowing null and blank password logins via SOAP API.] As a quick note, the /soap/api/ directory should be deleted or access denied on installations that don't need to use SOAP. The new /admin/check/ feature in the 1.3.x (development) branch already warns users to remove this directory if not required. Distributions are advised to consider disabling access to /soap/api by default (depending on whether you believe users are more likely to use or not use SOAP API). Thanks, David Hicks MantisBT Developer #mantisbt irc.freenode.net http://www.mantisbt.org/bugs/ [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ