Monday, December 29, 2008

Windows Media Player Integer Overflow.

Hi Folks, today a Windows Media Player Integer Overflow exploit comes out.
"Windows Media Player 11 for Windows XP offers great new ways to store and enjoy all your music, video, pictures, and recorded TV. Play it, view it, and sync it to a portable device for enjoying on the go or even share with devices
around your home—all from one place."
The author (laurent gaffiƩ) found that Windows Media Player fails to handle exceptional condition when parsing a malformed WAV,SND,MID file. Which can lead to a remote integrer overflow.

The canonical wave heap format is the following:



Where:

The canonical WAVE format starts with the RIFF header:

 ChunkID Contains the letters "RIFF" in ASCII form (0x52494646 big-endian form).
ChunkSize 36 + SubChunk2Size, or more precisely: 4 + (8 + SubChunk1Size) + (8 + SubChunk2Size) This is the size of the rest of the chunk following this number. This is the size of the  entire file in bytes minus 8 bytes for the two fields not included in this count: ChunkID and ChunkSize. 8 4 Format Contains the letters "WAVE" (0x57415645 big-endian form).

The "WAVE" format consists of two subchunks: "fmt " and "data":
The "fmt " subchunk describes the sound data's format:

Subchunk1ID Contains the letters "fmt " (0x666d7420 big-endian form).
Subchunk1Size 16 for PCM. This is the size of the rest of the Subchunk which follows this number. 20 2 AudioFormat PCM = 1 (i.e. Linear quantization) Values other than 1 indicate some form of compression.
NumChannels Mono = 1, Stereo = 2, etc.
SampleRate 8000, 44100, etc.
ByteRate == SampleRate * NumChannels * BitsPerSample/8
BlockAlign == NumChannels * BitsPerSample/8 The number of bytes for one sample including all channels. 
BitsPerSample 8 bits = 8, 16 bits = 16, etc.
ExtraParamSize if PCM, then doesn't exist
X ExtraParams space for extra parameters

The "data" subchunk contains the size of the data and the actual sound:

Subchunk2ID Contains the letters "data" (0x64617461 big-endian form).
Subchunk2Size == NumSamples * NumChannels * BitsPerSample/8 This is the number of bytes in the data. You can also think of this as the size of the read of the subchunk following this  number.
Data The actual sound data.


The exploit builds the following heap:




Which makes no sense. In fact, if you keep a normal WAVE heap looks like that:


Every single byte of the "exploit made" WAVE file  is bad formed, no RIFF, no WAVE, no fmt, nothing. An integer overflow comes out during the execution of this "bad formed" multimedia file which eventually allows a remote user to run arbitrary code on victim's  machine. The correct header should start with "52 49 46 46" and should have on byte 9 through byte 12 the word "57 41 56 45" ("WAVE") followed by "66 6d 74 20" ( fmt ). The following image should explain in a easy graphic way what I meant.


It's very strange discovering that Microsoft makes this mistakes. At the end of the day, with respect to laurent gaffie's work, this bug is a well known integer buffer overflow due to a missed control on a (probably) "error check" 's loop counter. Microsoft should know this problematics.

1 comment:

Meths said...

Great read and Happy New Year!