COMMAND

	Multiple MySQL vulnerabilities

SYSTEMS AFFECTED

	MySQL <= 3.23.53a, <= 4.0.5a

PROBLEM

	Thanks  to  Stefan  Esser  [s.esser@e-matters.de]  of   e-matters   GmbH
	[http://www.e-matters.de] advisory :
	
	 http://security.e-matters.de/advisories/042002.html
	
	
	--snip--
	
	While auditing the MySQL sourcetree we discovered  several  bugs  within
	the MySQL client and server that are listed below:
	   
	
	 +++ SERVER +++ COM_TABLE_DUMP - Signed Integer Vulnerability
	   
	When handling the COM_TABLE_DUMP package MySQL < 4.x takes two  chars
	from the packet, casts them directly to unsigned integers and uses  them
	as length parameters for memcpy. Obviously negative  values  within  the
	chars will turn into very big unsigned numbers. Because this is  a  heap
	to heap copy operation  and  there  is  no  memory  allocating  function
	within the SIGSEGV handler we strongly believe  this  bug  can  only  be
	used for denial of service attacks. Depending on the packet mysqld  will
	directly crash or hang in an endless loop of segmentation  faults.  This
	was tested against Windows, Linux and FreeBSD systems.
	 
	   
	 +++ SERVER +++ COM_CHANGE_USER - Password Length Vulnerability
	   
	In February 2000 Robert van der Meulen  discovered  a  flaw  within  the
	main password  authentication  system  of  MySQL:  The  MySQL  challenge
	response algorithm creates an expected response with exactly the  length
	of the response provided by the client. So if the client  sends  only  a
	one char response MySQL will check only one byte. But this means  it  is
	possible to give the correct response with only 32  tries  (because  the
	charset is only 32 chars big). When this  bug  was  fixed  in  2000  the
	MySQL authors simply added a check in the server that the response  must
	be 8  chars  long.  However  they  forgot  to  add  this  check  to  the
	COM_CHANGE_USER command, too. So it is still possible  for  an  attacker
	with a valid mysql-account to compromise the  other  accounts  that  are
	allowed to login from the same host. For a local user this means he  can
	break into the mysql root account and so compromise all databases.  This
	is especially dangerous in a shared environment or if the root  user  is
	allowed to login from other hosts than  localhost.  While  the  attacker
	can supply a one byte response to break into the other accounts  he  can
	also send an oversized one. If the response is longer than 16 chars  the
	internal created expected  answer  overflows  a  stack  buffer.  If  the
	response  is  long  enough  it  is  possible  to  overwrite  the   saved
	instruction pointer with bytes that are generated by the  random  number
	generator of the password  verification  algorithm.  While  this  sounds
	hard or impossible to exploit, we successfully  exploited  this  bug  on
	our linux maschines. Due to the fact that mysql restarts  on  crash  you
	have  unlimited  tries.  Because  of  the  limited  set  of   characters
	generated by the random number generator we strongly believe  that  this
	bug is not exploitable  on  Windows,  because  it  is  not  possible  to
	overwrite the instruction pointer with valid controllable addresses.
	  
	   
	 +++ CLIENT +++ libmysqlclient read_rows Overflow
	   
	When the MySQL client library receives answer rows from  the  server  it
	wants to copy the  answers  into  another  buffer.  Therefore  it  loops
	through the returned fields and copies them to the other location.  This
	is done without actually checking if the stored field sizes  are  within
	the  destination  buffer  boundaries.  Additionally  there  is  also   a
	terminating '\0' added to the end of all  fields  without  checking  for
	enough space within the destination buffer. Due to the  fact  that  this
	bug gets already triggered by a simple SELECT  query  anything  that  is
	linked against libmysql is potentially vulnerable. Due to the nature  of
	this bug it is trivial to use it as denial  of  service  attack  against
	the client applications (A negative fieldsize will do the  job).  If  it
	possible to use this overflow to execute code on the  client  system  is
	different from application to application.  It  depends  mainly  on  the
	fact if malloc() overflows are exploitable  on  that  particular  system
	and if the application allows enough control over the heap structure  by
	triggering different execution paths.
	   
	
	 +++ CLIENT +++ libmysqlclient read_one_row Byte Overwrittes 
	   
	When the MySQL client library fetchs one row from the  MySQL  server  it
	loops through the fields to remember pointers to the field  values.  The
	field sizes  are  trusted  and  not  checked  against  out  of  boundary
	conditions. After remembering the pointer the previous field  gets  zero
	terminated. A  malformed  packet  can  supply  any  field  size  and  so
	overwrite some arbitrary memory address with a '\0'. An invalid  address
	will of course crash the client. Because the address that is written  to
	is arbitrary (maybe hard to  supply  because  it  must  be  supplied  as
	delta) all clients that make use of fetching the answer row by  row  are
	most probably vulnerable to arbitrary code execution exploits.
	 
	   
	Finally it must be mentioned that  an  attacker  can  of  course  use  a
	combination of the described attacks to break into a system  or  to  get
	access to privileges he normaly does not own. f.e. it is possible for  a
	local user to crash the  server  with  the  COM_TABLE_DUMP  bug  (if  he
	cannot takeover the root account with the COM_CHANGE_USER bug) and  then
	bind a fake server to the MySQL port 3306. And with  a  fake  server  he
	can exploit the libmysqlclient overflow. Another scenario  would  be  an
	attacker that tries to exploit his favourite mod_scripting  language  to
	takeover the webserver by connecting to an external fake server...
	
	--snap--

SOLUTION

	Get MySQL 3.23.54