Re: CVE request: mantisbt before 1.2.9

[Kurt Seifried <kseifried () redhat com>]

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 () lists 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)