Flash Player/Plugin Video file parsing Code Execution
15 Jul. 2007
Summary
By using a specially crafted "flv" video it's possible to trigger an integer overflow inside Adobe Flash interpreter which could lead to client/browser-plugin crash, arbitrary code execution or system denial of service. All OS (Windows, Linux, MacOs,...) seem to be affected.
This is a very dangerous vulnerability, in fact, an attacker could force a flash video player that is already in place on a remote
web site to crash and execute arbitrary code in the context of the local machine.
"Metadata format description" states that for each object in the DataObject Section it's possible to define the name and the data type from a list of bytecodes:
0x00 = Number type
0x01 = Boolean type
0x02 = String type
0x03 = Object type
0x04 = MovieClip type
0x05 = Null type
0x06 = Undefined type
0x07 = Reference type
0x08 = ECMA array type
0x0a = Strict array type
0x0b = Date type
0x0c = Long string type
---
Furthermore there are other descriptors not described in the official adobe document:
Then after the name of the object for example, "onMetadata", there is the byte value which defines the proper datatype for the object (0x08 in our example).
The content datatype can be switched to any of the previous types, including "Long string type" (0x0c) and "XML" (0x0f) using an
HexEditor tool.
Byte "0x0c" states that a field will contain a long string; a long string has a lenght that must be defined:
The definer of the string length it's an (unsigned) int 32 bit.
By supplying a data type of 0x0c or 0x0f and then setting the length to the highest values (0xffffff) the client interpreter could crash or execute arbitrary code:
ECX is loaded with the large invalid value (0xFFFFFFFF) supplied by the attacker with a special crafted FLV file. The value is converted to 0x3FFFFFFF by SHR and is compared against 0x08 without a proper sign check.
As result, the next REP MOVS instruction will move an extremely large buffer from ESI->EDI and will overwrite critical regions of the memory.
Due to the memory corruption generated by REP MOVS instruction, Flash9b module will crash due to an access violation when writing. It has been observed that after the crash, the code execution is eventually redirected to the following code of the module:
CALL DWORD [EAX + X] ; where X is a constant value
EAX value gets loaded from a buffer pointed by ECX which is partially overwritten by the data coming from the malformed FLV file and so the remote code execution is reliable.
