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


TUCoPS :: Windows Net Apps :: win5033.htm

RealPlayer remote buffer overflow (heap & stack)



28th Jan 2002 [SBWID-5033]
COMMAND

	RealPlayer remote buffer overflow (heap & stack)

SYSTEMS AFFECTED

	 RealPlayer One

	 RealPlayer G2

	 RealPlayer 8

	 RealPlayer 7

PROBLEM

	In  Tim  Morgan  of   sentinelchicken   [http://www.sentinelchicken.com]
	advisory :
	

	The Real Media file format contains a variety of strings in its  header.
	By manipulating the way a file is formatted, it is possible to  overflow
	memory buffers which store these strings. Potentially, this could  allow
	an attacker to run arbitrary code on a victim\'s machine.
	

	The problem boils down to the fact that RealPlayer trusts the format  of
	input from real media files a  bit  too  much.  The  format,  generally,
	consists of two main blocks, a header and a stream. The header  contains
	many human-readable strings that delimit data and  sub-sections  of  the
	header. Looking at different files, one  can  see  that  most  of  these
	strings are optional and somewhat dynamic in nature.
	

	The interesting characteristic of these strings is  the  fact  that  the
	byte(s) (one or two) right before the beginning of  these  strings  tell
	RealPlayer how long the string is going to be. In addition, the  strings
	are almost always terminated with  a  00  byte.  One  would  think  that
	between this information and knowledge of how large your buffers are  in
	a program reading the file, it would be easy to avoid any overflows.
	

	As it turns out, RealPlayer blindly trusts the number in  front  of  the
	string to indicate the true length of the string, and doesn\'t check  to
	see if this number is smaller than the allocated  buffer  length.  Thus,
	with certain strings, it is very  easy  to  cause  RealPlayer  to  crash
	consistently by making the two bytes in front of a string 0xFFFF.
	

	For example, a piece of a header might look something like:
	

	...

	00000300   00 0D 43 72  65 61 74 69  6F 6E 20 44  61 74 65 00  ..Creation Date.

	00000310   00 00 02 00  13 36 2F 31  34 2F 32 30  30 30 20 31  .....6/14/2000 1

	00000320   30 3A 30 33  3A 31 38 00  00 00 00 31  00 00 11 4D  0:03:18....1...M

	00000330   6F 64 69 66  69 63 61 74  69 6F 6E 20  44 61 74 65  odification Date

	00000340   00 00 00 02  00 13 36 2F  31 34 2F 32  30 30 30 20  ......6/14/2000 

	00000350   31 30 3A 30  33 3A 31 38  00 00 00 00  39 00 00 07  10:03:18....9...

	00000360   46 69 6C 65  20 49 44 00  00 00 02 00  25 62 63 62  File ID.....%bcb

	00000370   30 37 35 39  33 2D 35 35  35 64 2D 64  32 39 64 2D  07593-555d-d29d-

	00000380   32 64 63 66  2D 62 38 62  36 31 66 38  65 66 66 31  2dcf-b8b61f8eff1

	00000390   36 00 00 00  00 16 00 00  08 4B 65 79  77 6F 72 64  6........Keyword

	...

	

	As you can see, there is a string at the front of this  clip  \"Creation
	Date\". The two bytes directly before it read 0x000D. This is the  exact
	length of our string. If we change those two bytes to  0xFFFF,  we  will
	likely cause RealPlayer to become unstable. Different strings reside  in
	different buffers, thus causing a wide variety of effects when they  are
	overflown. Additionally, due to the fact that the headers in Real  Media
	files are dynamic in size, it is very  easy  to  slip  large  chunks  of
	shell code into a file, without the parser complaining.
	

	It is just a matter of time before someone discovers a string that  gets
	them onto the stack with arbitrary code execution. That is,  if  someone
	hasn\'t already. The users of RealPlayer need to know.
	

	After examining this problem on Debian Linux with gdb,  it  appears,  by
	the addresses of the buffers, that the strings are generally  stored  on
	the heap. However, under certain odd conditions,  it  appears  to  crash
	while copying data onto  the  stack.  It  is  unknown  whether  this  is
	because of prior heap corruption. The locations of  these  buffers  have
	not yet been explored on Windows.
	

	A sample real media file that has been shown to cause crashes on a  wide
	number of platforms can be found at:
	

	http://www.sentinelchicken.net/files/firstrun.rm

	

	The file has had only two  bytes  changed  from  the  original  version,
	which is shipped with RealPlayer.
	

	The fact that most of these overflows appear to occur on the heap  makes
	it more difficult for exploit. Thus the medium risk factor.

SOLUTION

	Follow URL below for instructions :
	

	http://www.service.real.com/help/faq/security/bufferoverrun.html

	


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH