Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 06 Mar 2012 23:53:20 +1000
From: David Hicks <>
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
mailing list has been BCC'd to this email.

I have made public the relevant security issues reported on 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).

MantisBT < 1.2.9 array value for $g_private_bug_threshold configuration
option allows bypass of access checks

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

MantisBT < 1.2.9 copy/clone bug report action failed to leave an audit

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.

MantisBT < 1.2.9 delete_bug_threshold/bugnote_allow_user_edit_delete
access check bypass via SOAP API

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.

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

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.

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

[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


David Hicks
MantisBT Developer

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.