Home page logo

oss-sec logo oss-sec mailing list archives

Re: CVE request: mantisbt before 1.2.9
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 06 Mar 2012 12:29:36 -0700

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

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 

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 

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 

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 

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

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

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).


David Hicks MantisBT Developer #mantisbt irc.freenode.net 

Kurt Seifried Red Hat Security Response Team (SRT)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]