|Sentinel Chicken Networks|
Sentinel Chicken Networks Security Advisory #01
RealPlayer¤ 8 Buffer OverflowDate: Jan 24, 2002
Versions: RealPlayer 8 basic, others likely.
Platforms: Win9x/2000, Linux, others likely.
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 DescriptionRealPlayer¤ is a widely used, general purpose streaming media player available from real.com¤.
Problem OverviewThe 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 DetailsThe 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:
The file has had only two bytes changed from the original version, which is shipped with RealPlayer.
Potential ImpactThe 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.
Tim Morgan - (Who, to the contrary of certain news articles, is not a security expert.)
Assisted in determining depth of problem (possibility of exploit):
Testing on various platforms:
¤ 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.
Also available in IPv6.