Apple Image I/O EXR Compression Remote Code Execution Vulnerability(CVE-2016-4630)

### SUMMARY An exploitable heap based buffer overflow exists in the handling of EXR images on OS X. A crafted EXR document can lead to a heap based buffer overflow resulting in remote code execution. Vulnerability can be triggered via a saved EXR file delivered by other means when opened in any application using the Apple Image I/O API. ### TESTED VERSIONS OSX El Capitan - 10.11.4 ### PRODUCT URLs https://developer.apple.com/osx/download ### CVSSv3 SCORE 7.1 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N ### DETAILS This vulnerability is present in the Apple Image I/O API which is used for all image handling on OS X including rendering images in Preview. There exists a vulnerability in the parsing and handling of EXR images. A specially crafted EXR image file can lead to an out of bounds write and ultimately to remote code execution. OpenEXR is a high dynamic-range (HDR) image file format developed by Industrial Light & Magic for use in computer imaging applications and is used in all motion pictures currently in production. EXR uses 16-bit floating-point color component values. Since the IEEE-754 floating-point specification does not define a 16-bit format, EXR created the "half" format. Half values have 1 sign bit, 5 exponent bits, and 10 mantissa bits. This information is then read in as rows of x and y coordinates to draw the image. The vulnerability arises when the values read in are not properly sanitized. EXR includes support for multiple different compression formats. B44 compression is used in this case and ultimately leads to the vulnerability. Below is the crash that happens when running the trigger: ``` (lldb) disass -s $pc libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell: -> 0x7fff8bd3f0e0 <+448>: vmovups ymm0, ymmword ptr [rsi - 0x20] 0x7fff8bd3f0e5 <+453>: mov r11, rdi 0x7fff8bd3f0e8 <+456>: sub rdi, 0x1 0x7fff8bd3f0ec <+460>: and rdi, -0x20 0x7fff8bd3f0f0 <+464>: mov rcx, r11 0x7fff8bd3f0f3 <+467>: sub rcx, rdi 0x7fff8bd3f0f6 <+470>: sub rsi, rcx 0x7fff8bd3f0f9 <+473>: sub rdx, rcx (lldb) register read General Purpose Registers: rax = 0x000000a111951000 rbx = 0x000000a111951000 rcx = 0x00007fb3c9fd26e0 rdx = 0xffffffff00000028 rdi = 0x000000a011951028 rsi = 0x000000001194f028 rbp = 0x0000700000116cb0 rsp = 0x0000700000116cb0 r8 = 0x0000000000000000 r9 = 0x0000000000000004 r10 = 0x00007fb3c9fd276c r11 = 0x000000a000002000 r12 = 0x0000000000000024 r13 = 0x0000000000000000 r14 = 0xffffffff00000028 r15 = 0xffffffff80000014 rip = 0x00007fff8bd3f0e0 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 448 rflags = 0x0000000000010282 cs = 0x000000000000002b fs = 0x0000000000000000 gs = 0x0000000000000000 (lldb) bt * thread #10: tid = 0x2443c3c3, 0x00007fff8bd3f0e0 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 448, stop reason = EXC_BAD_ACCESS (code=1, address=0x1194f008) * frame #0: 0x00007fff8bd3f0e0 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 448 frame #1: 0x00000001115cf1c2 libOpenEXR.dylib`Imf_2_2::B44Compressor::uncompress(char const*, int, Imath_2_2::Box<Imath_2_2::Vec2<int> >, char const*&) + 2430 frame #2: 0x00000001115cf2c8 libOpenEXR.dylib`Imf_2_2::B44Compressor::uncompressTile(char const*, int, Imath_2_2::Box<Imath_2_2::Vec2<int> >, char const*&) + 26 frame #3: 0x00000001115c2ee1 libOpenEXR.dylib`Imf_2_2::(anonymous namespace)::TileBufferTask::execute() + 209 frame #4: 0x00000001116308ce libOpenEXR.dylib`IlmThread_2_2::(anonymous namespace)::WorkerThread::run() + 162 frame #5: 0x00007fff9117699d libsystem_pthread.dylib`_pthread_body + 131 frame #6: 0x00007fff9117691a libsystem_pthread.dylib`_pthread_start + 168 frame #7: 0x00007fff91174351 libsystem_pthread.dylib`thread_start + 13 ``` And running the trigger again except with guard malloc enabled this time shows us some interesting output: ``` GuardMalloc[Preview-98952]: Attempting excessively large memory allocation: 687194773760 bytes GuardMalloc[Preview-98952]: If you really wanted to allocate so much memory, launch your executable with the environment variable MALLOC_PERMIT_INSANE_REQUESTS set to any value to circumvent this check. GuardMalloc[Preview-98952]: Explicitly trapping into debugger!!! ``` The large malloc is caused by a user controlled value for the size of the compressed B44 data. This pointer ultimately gets stored in an int despite the fact that it is the size of long. This ultimately causes truncation of the malloced value leading to an out of bounds access. This is a direct memcpy of user controlled data into an out of bounds buffer and could be leveraged to gain full remote code execution. ### CRASH INFORMATION ``` Crashed thread log = 0 libsystem_platform.dylib 0x00007fff8bd3f0e0 _platform_memmove$VARIANT$Haswell + 448 1 libOpenEXR.dylib 0x0000000110f7b1c2 Imf_2_2::B44Compressor::uncompress(char const*, int, Imath_2_2::Box<Imath_2_2::Vec2<int> >, char const*&) + 2430 2 libOpenEXR.dylib 0x0000000110f7b2c8 Imf_2_2::B44Compressor::uncompressTile(char const*, int, Imath_2_2::Box<Imath_2_2::Vec2<int> >, char const*&) + 26 3 libOpenEXR.dylib 0x0000000110f6eee1 Imf_2_2::(anonymous namespace)::TileBufferTask::execute() + 209 4 libOpenEXR.dylib 0x0000000110fdc8ce IlmThread_2_2::(anonymous namespace)::WorkerThread::run() + 162 5 libsystem_pthread.dylib 0x00007fff9117699d _pthread_body + 131 6 libsystem_pthread.dylib 0x00007fff9117691a _pthread_start + 168 7 libsystem_pthread.dylib 0x00007fff91174351 thread_start + 13 --- exception=EXC_BAD_ACCESS:signal=11:is_exploitable=yes:instruction_disassembly=.byte 0xc5 #bad opcode:instruction_address=0x00007fff8bd3f0e0:access_type=unknown:access_address=0x00000000118e8008: Crash accessing invalid address. Consider running it again with libgmalloc(3) to see if the log changes. ``` ### TIMELINE * 2016-05-16 - Vendor Disclosure * 2016-07-18 - Public Release