MOAB-27-01-2007: Telestream Flip4Mac WMV Parsing Memory Corruption Vulnerability

Summary

The vendor (Telestream) provides the following description of the software:

Flip4Mac™ WMV is a collection of QuickTime components that allow you to play, import, and export Windows Media video and audio files on your Mac using your favorite QuickTime-based applications. 

WMV files use the Advanced Systems Format (ASF) container format, originally supported for Macintosh systems via Microsoft's "Windows Media Player for Mac". Since Microsoft decided to stop development of it's Mac-port of WM Player, Flip4Mac became the 'endorsed', somehow official solution.

It fails to properly handle WMV files with a crafted ASF_File_Properties_Object size field, leading to an exploitable memory corruption condition, which can be abused remotely for arbitrary code execution.

ASF_File_Properties_Object:
8CABDCA1-A947-11CF-8EE4-00C00C205365 71494647607722088 112 --| GUID
0x70: A1 DC AB 8C 47 A9 CF 11 8E E4 00 C0 0C 20 53 65 ----/
0x80: 68 00 00 FF 00 00 00 00 63 79 0C 20 28 50 D5 11 [size at 0x80]

See the 'Debugging information' section for further details.
Affected versions

Verified with QuickTime™ Player Version 7.1.3 and Windows Media ® Components for Quicktime Version 2.1.0.33, on Mac OS X 10.4.8 (8L2127), x86.
Proof of concept, exploit or instructions to reproduce

The sample proof of concept provided shows saved eip being overwritten with a bogus address (it's known to not work on PowerPC, as the conditions are slightly different).
Debugging information

The following debugging information shows Quicktime triggering the issue when opening the provided proof of concept WMV file.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xff3472b0
0xffff0b08 in ___memcpy () at /System/…/i386/cpu_capabilities.h:228
228 in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h
(gdb) back
#0 0xffff0b08 in ___memcpy () at /System/…/i386/cpu_capabilities.h:228
#1 0xff000050 in ?? ()
#2 0x011ae3ff in MjpgDecompressorComponentDispatch ()
#3 0x011b2504 in MjpgDecompressorComponentDispatch ()
#4 0x011af955 in MjpgDecompressorComponentDispatch ()
#5 0x0101d617 in MmsDataHandlerComponentDispatch ()
#6 0x011b1791 in MjpgDecompressorComponentDispatch ()
#7 0x0100dc82 in AsfMovieImportComponentDispatch ()
#8 0x01013c28 in AsfMovieImportComponentDispatch ()
#9 0x90cccf6e in CallComponentFunctionCommon ()
#10 0x0100b005 in AsfMovieImportComponentDispatch ()
#11 0x90ccca3c in CallComponentDispatch ()
#12 0x94390dc6 in MovieImportDataRef ()
#13 0x0100a45f in dyld_stub_TECGetEncodingList ()
#14 0x90cccf6e in CallComponentFunctionCommon ()
#15 0x0100b005 in AsfMovieImportComponentDispatch ()
#16 0x90ccca3c in CallComponentDispatch ()
#17 0x943b7656 in MovieImportFile ()
#18 0x943b749c in newMovieFromFileFromComponent ()
#19 0x9430678d in getNewMovieFromFileUsingImporters ()
#20 0x94306131 in NewMovieFromFilePriv ()
#21 0x94302778 in NewMovieFromDataRefPriv_priv ()
#22 0x9430145e in NewMovieFromProperties_priv ()
#23 0x95a2e980 in -[QTMovie initWithAttributes:error:] ()
#24 0x95a2cf91 in +[QTMovie movieWithAttributes:error:] ()
#25 0x0000ad3b in -[QTPMovieDocument readFromFile:ofType:] ()
#26 0x0000ac08 in -[QTPMovieDocument initWithContentsOfFile:ofType:isHotPicks:] ()
#27 0x00013153 in -[QTPMovieDocument initWithContentsOfFile:ofType:] ()
#28 0x934fd82b in -[NSDocumentController(NSDeprecated) makeDocumentWithContentsOfFile:ofType:] ()
#29 0x93541c31 in -[NSDocumentController(NSDeprecated) _openDocumentFileAt:display:] ()
#30 0x00012ee9 in -[QTPApplicationDelegate openFiles:openInNewPlayer:] ()
#31 0x00012daf in -[QTPApplicationDelegate application:openFiles:] ()
#32 0x9326ad3b in -[NSApplication _doOpenFile:ok:tryTemp:] ()
#33 0x93268305 in -[NSApplication finishLaunching] ()
#34 0x93267c29 in -[NSApplication run] ()
#35 0x9325bd2f in NSApplicationMain ()
#36 0x0004040a in _start ()
#37 0x00040325 in start ()

(gdb) x/x $esp
0xbfffe3f0: 0xff000050

The saved eip for the current frame has been overwritten with a bogus address:

(gdb) i f
Stack level 0, frame at 0xbfffe3f8:
eip = 0xffff0b08 in ___memcpy (/System/…/cpu_capabilities.h:228); saved eip 0xff000050
called by frame at 0xbfffe400
source language unknown.
Arglist at 0xbfffe3f0, args:
Locals at 0xbfffe3f0, Previous frame's sp is 0xbfffe3f4
Saved registers:
eip at 0xbfffe3f0
(gdb) x/x 0xff000050
0xff000050: Cannot access memory at address 0xff000050
(gdb) x/10 0xbfffe3f0
0xbfffe3f0: 0xff000050 0xbfffe458 0xbfffe418 0x011ae3ff
0xbfffe400: 0x00347270 0x01836a70 0xff000050 0x90002448
0xbfffe410: 0x00347250 0xbfffe470

(gdb) DM 0x00347250 40
Displaying memory from 00347250
00347250: A8DA 2001 0100 0000 A1DC AB8C 47A9 CF11 … …G…
00347260: 8EE4 00C0 0C20 5365 6800 00FF 0000 0000 … Seh…
00347270: 0000 0000 0000 0000 …

The above stream is actually the content of the WMV file from offset 0x70 to 0x90.
Notes
Exploitation conditions

Given that we can overwrite saved eip (and thus subvert the execution flow) and provide any payload of our choice by appending it to the WMV file, exploitation for arbitrary code execution is clearly possible. Although, the conditions for PowerPC and x86 are slightly different, and thus the same file won't work for both architectures (this has nothing to do with payload limitations, as we can use one that will work for both ppc and x86, like nemo's multi-arch shellcode).

A working exploit for this issue might be developed later today and released as soon as it's been tested and known to be reliable.
Workaround or temporary solution

Disable Flip4Mac and/or automated opening of WMV files, and wait for a patch to be released by the vendor (Telestream).