RealPlayer Buffer Problem

[tmorgan-security () kavi com]

Hello,

I have been sitting on/working on this one for a while, but I am not
experienced with Buffer overflows, so I have not yet been able to
produce a proof-of-concept exploit.  I was hoping that someone on
the list would be luckier than I, or at least explain exactly what
is possible. Thanks in advance for your help.

Consistent crashes achieved on:
 Windows 98SE, 2000, ME
 Debian/GNU Linux Stable

These crashes have occurred in multiple versions of the Real Media
file format including the G2 format and older formats.

The nitty gritty:

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 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.  This is not the case however.

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.

Now I have been examining this problem on Debian Linux with gdb
which has lead me to believe, 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.  Whether this is because of prior heap corruption, I do
not know.  I do not have debugging facilities in the various flavors
of windows that I have tested it on, so I have no idea where things
are stored on those systems.

I am perfectly willing to provide data I have gleaned from gdb, but
I would like people to test it out for themselves first if possible.
I do have a sample file for download which seems to immediately and
consistently crash any RealPlayer that tries to open it.  If anyone
find differently, I would like to know about it.  The file is
located at:

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

I actually just modified the music file that plays when you first
install and run RealPlayer, so if you want to do the modification
yourself, thus saving us all some bandwidth, just do the following:

Whip out your hex editor and change the two bytes at offset 0x036b
from 0x0025 to 0xffff.  That is of course if you have the same
version of firstrun.rm as I.  From my earlier description, you
should be able to figure out how to duplicate it though, either way.
The field I changed was the File Id field.

Thanks again for your time, and I look forward to learning more
about this bug.

Tim