To reproduce, use the attached SWF that loads the attached malformed mp4 file. I believe the root cause of the bug is that an unexpected ordering of mp4 tags leads to an out-of-bounds write. Specifically, if the mp4 file lacks any tracks and then hits a tag which is describing a property of the current track, the fault will occur.

On a 64-bit build:

=> 0x0000000000b7b639:	mov    %eax,0xc(%rdx)

rax            0x41414141	1094795585
rdx            0x8187e4920fd8	142420655345624

As can be seen, the value being written to the out-of-bounds location is under attacker control. The out-of-bounds location appears to be quite wild, perhaps +4GB out-of-bounds. An example of how to exploit such issues, even in the presence of a memory limit, is covered on the Project Zero blog: http://googleprojectzero.blogspot.com/2014/09/exploiting-cve-2014-0556-in-flash.html

On 32-bit, I believe the corruption will be much more subtle, always landing in an allocated chunk, due to address-space wrap around at 4GB. I'd expect the issue to be more reliably exploitable on 32-bit, but even getting a PoC that crashes on 32-bit would be a lot more work.


This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

 

LoadMP4.as 878 bytes Download

LoadMP4.swf 963 bytes Download

test.mp4 20 bytes Download