Talos Vulnerability Report

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