[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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/
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.
