Sentinel Chicken Networks Security Advisory #01

RealPlayer^¤ 8 Buffer Overflow

Date: Jan 24, 2002
Risk: Medium
Versions: RealPlayer 8 basic, others likely.
Platforms: Win9x/2000, Linux, others likely.

Vendor Notification:
  Vendor first contacted on 1/17/2002.
  Vendor announced on 1/24/2002 that a patch would be available on 1/25/2002.
  UPDATE: Patch is now available from Real.
        (Page also contains updated information on affected versions and platforms.)

Product Description

RealPlayer^¤ is a widely used, general purpose streaming media player available from real.com^¤.

Problem Overview

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.

Technical Details

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.com/data/advisories/realplayer/firstrun.rm
The file has had only two bytes changed from the original version, which is shipped with RealPlayer.

Potential Impact

The potential of this problem is pretty self evident. However, the fact that most of these overflows appear to occur on the heap makes it more difficult for exploit. Thus the medium risk factor. However, as with any buffer overflow, conclusively proving that it is not can be quite difficult.

We have yet to find a version of RealPlayer that is not vulnerable to this type of attack. If an exploit is found and disseminated through the black hat community, the impact could be very far reaching.

Credits

Discovered by:
  Tim Morgan - (Who, to the contrary of certain news articles, is not a security expert.)

Assisted in determining depth of problem (possibility of exploit):
  Marc Slemko
  Leper

Testing on various platforms:
  Leper
  Eli Mumford

^¤ Names, marks, products, and gadgets listed in this advisory are owned by their respective, paranoid, companies.

This advisory is intended for educational use only. It is the sincere hope of the author that this information will help protect the public from the vulnerability discussed. Where possible, the author has made a reasonable effort to contact vendors and release only after patches/work-arounds are made available. The author(s) will not take responsibility for any possible negative effects of its dissemination.

Content on this page, unless otherwise indicated, is © 2002-2010 Sentinel Chicken Networks. Reproduction is authorized under our terms.
printer friendly Also available in IPv6.