Date: Tue, 06 Mar 2012 12:29:36 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: David Hicks <d@...id.au> Subject: Re: CVE request: mantisbt before 1.2.9 On 03/06/2012 06:53 AM, David Hicks wrote: > 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). This makes my life sooo much easier, thank you! > 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.] Please use CVE-2012-1118 for this issue > 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. Please use CVE-2012-1119 for this issue > 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. Please use CVE-2012-1120 for this issue > 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. Please use CVE-2012-1121 for this issue > 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. Please use CVE-2012-1122 for this issue > 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.] Please use CVE-2012-1123 for this issue In summary: CVE-2012-1118 MantisBT 1.2.8 10124 array value for $g_private_bug_threshold configuration option allows bypass of access checks CVE-2012-1119 MantisBT 1.2.8 13816 copy/clone bug report action failed to leave an audit trail CVE-2012-1120 MantisBT 1.2.8 13656 elete_bug_threshold/bugnote_allow_user_edit_delete access check bypass via SOAP API CVE-2012-1121 MantisBT 1.2.8 13561 managers of specific projects could update global category settings CVE-2012-1122 MantisBT 1.2.8 13748 incorrect access checks performed when moving bugs between projects CVE-2012-1123 MantisBT 1.2.8 13901 SOAP API null password authentication bypass > 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/ -- Kurt Seifried Red Hat Security Response Team (SRT)
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