[UNIX] Mantis Bug Tracker Multiple Vulnerabilities (XSS, CSRF, Code Execution)
- From: SecuriTeam <support@xxxxxxxxxxxxxx>
- Date: 21 May 2008 13:54:44 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Mantis Bug Tracker Multiple Vulnerabilities (XSS, CSRF, Code Execution)
------------------------------------------------------------------------
SUMMARY
" <http://www.mantisbt.org/> Mantis is a free popular web-based bug
tracking system. It is written in the PHP scripting language and works
with MySQL, MS SQL, and PostgreSQL databases and a webserver.". Multiple
vulnerabilities exist in the Mantis software (XSS, CSRF, Remote Code
Execution).
DETAILS
Vulnerable Systems:
* Mantis version 1.1.1
Immune Systems:
* Mantis version 1.1.2 (with an appropriate patch)
* Mantis version 1.2.0a1
XSS Vulnerabilities
We have found an XSS vulnerability in return_dynamic_filters.php. In order
to exploit this vulnerability the attacker must be authenticated. Usually
the anonymous user is allowed on typical installation, so the impact is a
bit higher. The following url is a proof of concept:
http://www.example.com/mantis/return_dynamic_filters.php?filter_target=
<script>alert(document.cookie);</script>
CSRF Vulnerabilities
There is a Cross Site Request Forgery vulnerability in the software. If a
logged in user with administrator privileges clicks on the following url:
http://www.example.com/mantis/manage_user_create.php?username=foo&realn
ame=aa&password=aa&password_verify=aa&email=foo@xxxxxxxxxxxx&access_lev
el=90&protected=0&enabled=1
a new user 'foo' with administrator privileges is created. The password of
the new user is sent to foo@xxxxxxxxxxxxx
Remote Code Execution Vulnerabilities
Finally we present the most critical vulnerability. A Remote Code
Execution vulnerability exists in the software, but it can be exploited
only if the attacker has a valid administrator account, so it could be
ideal if used in conjunction with the previous one. The vulnerability is
in the file adm_config_set.php. On row 80 we have the following statement:
eval( '$t_value = ' . $f_value . ';' );
where the $f_value is defined at row 34 of the same file:
$f_value = gpc_get_string( 'value' );
the parameter $f_value is never validated, so we can exploit this issue
with the following url which executes the phpinfo() function:
http://www.example.com/mantis/adm_config_set.php?user_id=0&project_id=0
&config_option=cache_config&type=0&value=0;phpinfo()
Workaround:
Proper input validation will fix the vulnerabilities.
Upgrade to latest development version 1.2.0a1
Vendor response:
It was a little surprise to find out that somebody issued CVE-2008-2276
during our responsible disclosure time-line.
From an internal email with Glenn Henshaw:# 8974 : XSS Vulnerability in filters - fixed for 1.1.2
# 8977 : Port 0008974: XSS Vulnerability in filters - fixed for 1.2.0 and
future - this issue has been fixed by escaping the data in the error
message.
# 8976 : Remote Code Execution in adm_config - workaround in place in
1.1.2 - this page is only accessible to registered administrators
# 8980 : Port: Remote Code Execution in adm_config - workaround in place
in 1.2.0 and beyond - this page is only accessible to registered
administrators
# 8975 : CSRF Vulnerabilities in user_create
# 8995 : Port: CSRF Vulnerabilities in user_create - this has been fixed
by ensuring that action pages can only be accessed via POST commands.
So "CSRF Vulnerabilities in user_create" is our finding. The vendor fixed
by allowing only POST parameters that is obviously a non-fix. Our
response:
This alone isn't enough since forms can be auto-submitted by js that are
irrespective of the same-orgin policy.
Proper remediation should include referer checking (has proved to be
spoofable on the client side in the past so not a bulletproof technique)
and token checking (a random string or an hash generated when the user
requires the frontend, stored serverside - sessions are okay -, included
in the frontend form and sent to and verified by the backend).
These two protections ensure that an action cannot, hopefully, be CSRFed
(at last in absence of an xss vuln that neutralize the same origin policy
again).
Glenn response:
Thanks for the notice. The CSRF patch for rev 1.1.2 is in place using just
a "POST" check. I have added a more sophisticated token based check to rev
1.2.0 (the patch is attached for review). I should be submitting this
shortly.
Glenn final update about the patch not being incorporated upstream:
As a final update on this subject, the status of these issues has not
changed. The token based CSRF implementation was rejected by the
development team, and will not be implemented (at least by me). The
consensus was that it was too complex to resolve a "rare" problem.
Since responsible disclosure didn't worked well with this vendor and
turned out to be very resource expensive we will publish future issues
affecting this product directly to independent security researchers,
developers and users.
The wrong attribution of CVE-2008-2276 before our official advisory
strengthen our conviction that responsible disclosure isn't always fair.
We discussed long with Glenn Henshaw about issues and how to fix them in
mantis and we didn't expect to find a CVE credited to one of our
interlocutors. He was surely aware of who was deserving credits and should
have taken proper steps to prevent or fix this.
Disclosure timeline:
20080121 Bug discovered
20080213 Vendor contacted -- LONG VENDOR SLOWNESS --
20080512 Last vendor mail about development and compatibility issues
20080515 CVE-2008-2276 wrongly credited to Glenn Henshaw (thraxisp)
20080520 Advisory released (forced disclosure)
ADDITIONAL INFORMATION
The information has been provided by <mailto:ascii@xxxxxxxxxxxx> ascii.
The original article can be found at:
<http://www.ush.it/team/ush/hack-mantis111/adv.txt>
http://www.ush.it/team/ush/hack-mantis111/adv.txt
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Prev by Date: [NEWS] Borland Interbase 2007 Integer Overflow
- Next by Date: [NEWS] Multiple Vendor Snort IP Fragment TTL Evasion Vulnerability
- Previous by thread: [NEWS] Borland Interbase 2007 Integer Overflow
- Next by thread: [NEWS] Multiple Vendor Snort IP Fragment TTL Evasion Vulnerability
- Index(es):
Relevant Pages
|
