Vulnerabilities > CVE-2016-4631 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Apple products

047910
CVSS 8.8 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
HIGH
Integrity impact
HIGH
Availability impact
HIGH
network
low complexity
apple
CWE-119
nessus
NVD
Published: 2016-07-22
Updated: 2024-11-21

Summary

ImageIO in Apple iOS before 9.3.3, OS X before 10.11.6, tvOS before 9.2.2, and watchOS before 2.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted TIFF file.

Vulnerable Configurations

Part Description Count
OS
Apple
303

Common Weakness Enumeration (CWE)

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Buffer Overflow via Environment Variables
    This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
  • Overflow Buffers
    Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
  • Client-side Injection-induced Buffer Overflow
    This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
  • Filter Failure through Buffer Overflow
    In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
  • MIME Conversion
    An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.

Nessus

  • NASL familyMisc.
    NASL idAPPLETV_9_2_2.NASL
    descriptionAccording to its banner, the version of the remote Apple TV device is prior to 9.2.2. It is, therefore, affected by multiple vulnerabilities in the following components : - CoreGraphics - ImageIO - IOAcceleratorFamily - IOHIDFamily - Kernel - libxml2 - libxslt - Sandbox Profiles - WebKit - WebKit Page Loading Note that only 4th generation models are affected by the vulnerabilities.
    last seen2020-06-01
    modified2020-06-02
    plugin id92494
    published2016-07-21
    reporterThis script is Copyright (C) 2016-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/92494
    titleApple TV < 9.2.2 Multiple Vulnerabilities
  • NASL familyMacOS X Local Security Checks
    NASL idMACOSX_10_11_6.NASL
    descriptionThe remote host is running a version of Mac OS X that is 10.11.x prior to 10.11.6. It is, therefore, affected by multiple vulnerabilities in the following components : - apache_mod_php - Audio - bsdiff - CFNetwork - CoreGraphics - FaceTime - Graphics Drivers - ImageIO - Intel Graphics Driver - IOHIDFamily - IOKit - IOSurface - Kernel - libc++abi - libexpat - LibreSSL - libxml2 - libxslt - Login Window - OpenSSL - QuickTime - Safari Login AutoFill - Sandbox Profiles Note that successful exploitation of the most serious issues can result in arbitrary code execution.
    last seen2020-06-01
    modified2020-06-02
    plugin id92496
    published2016-07-21
    reporterThis script is Copyright (C) 2016-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
    sourcehttps://www.tenable.com/plugins/nessus/92496
    titleMac OS X 10.11.x < 10.11.6 Multiple Vulnerabilities

Seebug

bulletinFamilyexploit
description### SUMMARY An exploitable heap based buffer overflow exists in the handling of TIFF images on Apple OS X and iOS operating systems. A crafted TIFF document can lead to a heap based buffer overflow resulting in remote code execution. This vulnerability can be triggered via malicious web page, MMS message, iMessage or a file attachment delivered by other means when opened in applications using the Apple Image I/O API. ### TESTED VERSIONS OSX El Capitan - 10.11.4 iOS - 9.3.1 ### PRODUCT URLs https://developer.apple.com/osx/download/ ### CVSSv3 SCORE 8.1 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N ### DETAILS This vulnerability is present in the Apple Image IO API which is used for all image handling on OS X including rendering images in Preview and Safari. There exists a vulnerability in the parsing and handling of Tiled TIFF images. A specially crafted TIFF image file can lead to an out of bounds write and ultimately to remote code execution. TIFF (Tagged Image File Format) images consist of data describing the image in the header then tags throughout the image file describing how and where the data should be displayed. Running the attached test case through a Tiff analyzer shows us the following output: ``` TIFFFetchNormalTag: Warning, Nonstandard tile width 255, convert file. TIFFFetchNormalTag: Warning, IO error during reading of "DocumentName"; tag ignored. TIFFFetchNormalTag: Warning, Incompatible type for "ResolutionUnit"; tag ignored. TIFFReadDirectory: Warning, Incorrect count for "ColorMap"; tag ignored. TIFFReadDirectory: Warning, TIFF directory is missing required "StripByteCounts" field, calculating from imagelength. TIFF Directory at offset 0xa0 (160) Image Width: 2 Image Length: 1 Tile Width: 255 Tile Length: 1024 Resolution: 72, 72 Bits/Sample: 8 Compression Scheme: None Photometric Interpretation: separated FillOrder: msb-to-lsb Orientation: row 0 bottom, col 0 rhs Samples/Pixel: 4 Rows/Strip: 1024 Planar Configuration: separate image planes Page Number: 0-1 ``` Each piece of information shown here is derived from a tag with a specific identifier in the image file. Take note of the warning alerting the user that the tile width is invalid. Running this through Preview the following output is shown: ``` Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: abort() called *** error for object 0x7f8a89f4e6b8: incorrect checksum for freed object - object was probably modified after being freed. 0 libsystem_kernel.dylib 0x00007fff9242df06 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff911794ec pthread_kill + 90 2 libsystem_c.dylib 0x00007fff95b436e7 abort + 129 3 libsystem_malloc.dylib 0x00007fff97f53396 szone_error + 626 4 libsystem_malloc.dylib 0x00007fff97f46c03 tiny_malloc_from_free_list + 1351 5 libsystem_malloc.dylib 0x00007fff97f45705 szone_malloc_should_clear + 292 6 libsystem_malloc.dylib 0x00007fff97f455a1 malloc_zone_malloc + 71 7 libsystem_malloc.dylib 0x00007fff97f440cc malloc + 42 8 libsystem_c.dylib 0x00007fff95b29e7b _vasprintf + 354 9 libsystem_c.dylib 0x00007fff95b211a8 asprintf + 186 10 com.apple.ImageIO.framework 0x00007fff8d394b05 ImageIOLogger + 97 11 com.apple.ImageIO.framework 0x00007fff8d33d43e myErrorHandler + 9 12 libTIFF.dylib 0x00007fff9d4667aa TIFFErrorExt + 179 13 libTIFF.dylib 0x00007fff9d480214 TIFFReadRawTile1 + 336 14 libTIFF.dylib 0x00007fff9d47fe78 TIFFFillTile + 384 15 libTIFF.dylib 0x00007fff9d47fc8a TIFFReadEncodedTile + 95 16 com.apple.ImageIO.framework 0x00007fff8d33d9b8 copyImageBlockSetTiledTIFF + 1372 17 com.apple.ImageIO.framework 0x00007fff8d2f40f4 ImageProviderCopyImageBlockSetCallback + 651 18 com.apple.CoreGraphics 0x00007fff93f15cb4 CGImageProviderCopyImageBlockSetWithOptions + 132 19 com.apple.CoreGraphics 0x00007fff93f1739c CGImageProviderCopyImageBlockSet + 205 20 com.apple.CoreGraphics 0x00007fff93f4e7fd img_blocks_create + 517 ``` It can be seen that this is corrupting a free heap block header so this is most likely a heap overflow. Now turning on guard malloc and reproducing the crash gives us the following output: ``` * thread #1: tid = 0x918fde, 0x00007fff8bd3f01c libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 252, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x12d9cc000) frame #0: 0x00007fff8bd3f01c libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 252 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell: -> 0x7fff8bd3f01c <+252>: vmovups %ymm0, (%rax) 0x7fff8bd3f020 <+256>: vmovups 0x20(%rsi), %ymm2 0x7fff8bd3f025 <+261>: addq $0x40, %rsi 0x7fff8bd3f029 <+265>: subq $0x80, %rdx (lldb) register read General Purpose Registers: rax = 0x000000012d9cbfff rbx = 0x000000012c62bb30 rcx = 0x0000000000000001 rdx = 0x00000000000000fe rdi = 0x000000012c64c000 rsi = 0x000000012c659c01 rbp = 0x00007fff5fbf9d90 rsp = 0x00007fff5fbf9d90 r8 = 0x00000000000000ff r9 = 0x00000000000000ff r10 = 0x00000000ffffff01 r11 = 0xffffffffffff23ff r12 = 0x000000012c64bfff r13 = 0x0000000000000001 r14 = 0x00000000000000ff r15 = 0x00000000000000ff rip = 0x00007fff8bd3f01c rflags = 0x0000000000010202 (lldb) bt frame #0: 0x00007fff8bd3f01c libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 252 frame #1: 0x00007fff9d459283 libTIFF.dylib`_TIFFmemcpy + 9 frame #2: 0x00007fff9d461870 libTIFF.dylib`DumpModeDecode + 92 frame #3: 0x00007fff9d47fcaf libTIFF.dylib`TIFFReadEncodedTile + 132 frame #4: 0x00007fff8d33d9b8 ImageIO`copyImageBlockSetTiledTIFF + 1372 frame #5: 0x00007fff8d2f40f4 ImageIO`ImageProviderCopyImageBlockSetCallback + 651 frame #6: 0x00007fff93f15cb4 CoreGraphics`CGImageProviderCopyImageBlockSetWithOptions + 132 frame #7: 0x00007fff93f1739c CoreGraphics`CGImageProviderCopyImageBlockSet + 205 (lldb) malloc_info $rax 0x000000012d9cbfff: malloc( 256) -> 0x12d9cbf00 + 255 (lldb) malloc_info -S $rax ColorSync Utility(54051,0x7fff79aef000) malloc: process 54687 no longer exists, stack logs deleted from /tmp/stack-logs.54687.100084000.ColorSync Utility.2vS0Sg.index 0x000000012d9cbfff: malloc( 256) -> 0x12d9cbf00 + 255 stack[0]: addr = 0x12d9cbf00, type=malloc, frames: [0] 0x00007fff97f489ce libsystem_malloc.dylib`malloc_zone_calloc + 118 [1] 0x00007fff97f49462 libsystem_malloc.dylib`calloc + 49 [2] 0x00007fff8d33d815 ImageIO`copyImageBlockSetTiledTIFF + 953 [3] 0x00007fff8d2f40f4 ImageIO`ImageProviderCopyImageBlockSetCallback + 651 ``` Here we see a crash on an attempt to write to memory at the address held in RAX. Investigating further we see RAX is pointing to the very end of a heap block yet there is still a lot of data to be written as RDX (counter) is still 0xFE. It is also noted that the malloced buffer is the same size as the tile width which becomes of interest when looking further into what is causing this. Decompiling the code near where the malloc block is allocated in ImageIO`copyImageBlockSetTiledTIFF` is shown below: ``` _cg_TIFFGetField(tiff, 322LL, &tile_width); _cg_TIFFGetField(tiff, 323LL, &tile_length); LODWORD(v16) = _cg_TIFFTileSize(tiff); if ( v16 < *(_QWORD *)(tiff + 816) ) v16 = *(_QWORD *)(tiff + 816); tile_size = v16; // 255 _cg_TIFFTileRowSize(tiff); num_samples = *(_QWORD *)(a2 + 264); ... width = tile_width; if ( tile_width > image_width ) [1] { tile_width = image_width; width = image_width; } tiff_Structure = tiff; length = tile_length; if ( tile_length > image_length ) [2] { tile_length = image_length; length = image_length; } width_ = width; samples_X_width = num_samples * width; [3] ... calloc_size_1 = samples_X_width * length; [4] if ( samples_X_width * (unsigned __int64)length < tile_size )[5] calloc_size_1 = tile_size; *(_QWORD *)(v157 + 128) = samples_X_width; vuln_buffer = (char *)calloc(calloc_size_1, 1uLL); ``` The information is read in from the tiff image then some calculations are performed on it. At [1] it compares the tile width and the image width and defaults to the smaller value. It does the same check for image length at [2]. The tile width and length, 255 and 1024, are both longer than the image width and length, 2 and 1, thus the code defaults to the smaller values. It then calculates the needed size by multiplying the calculated width from above, times the number of samples[4]. If this is less than the size of a tile, one tile size is allocated, 255, which is what happens in this case[5]. Further into this function we see where our overwrite is happening: ``` cur_sample = 0LL; if ( num_samples ) { do { ... bytes_read = _cg_TIFFReadTile( tiff_Structure, vuln_buffer, (unsigned int)x, (unsigned int)y, 0LL, (unsigned __int16)cur_sample); vuln_buffer += bytes_read; [1] ++cur_sample; } while ( num_samples != cur_sample ); } ``` The code is reading in tile data from the tiff image, one tile per sample, and moving the buffer forward the size of one tile[1]. The problem comes in when we look at the previous code and see it defaulted to the smaller width and only allocated 255 bytes, enough for one sample. Every subsequent sample writes out of bounds and further corrupts memory. The number of samples is easily controlled in the tiff image allowing for further heap corruption quite easily. ### CRASH INFORMATION ``` Testing Quick Look preview with files: bunny.tif May 6 16:00:54 qlmanage[55235] <Warning>: ImageIO: readAndCreateASCIIString Unable to read ASCII TIFF Tag #269 with reported length (8) May 6 16:00:54 qlmanage[55235] <Warning>: ImageIO: readAndCreateASCIIString Unable to read ASCII TIFF Tag #269 with reported length (8) May 6 16:00:54 qlmanage[55235] <Warning>: ImageIO: readAndCreateASCIIString Unable to read ASCII TIFF Tag #269 with reported length (8) Crashed thread log = : Dispatch queue: com.apple.root.default-qos 0 com.apple.ColorSync 0x00007fff9357070f CollectFlattenedConversion(CMMConvNode*, CMMMemMgr*, bool, __CFArray*) + 49 1 com.apple.ColorSync 0x00007fff935707d4 DoFlattenFullConversion + 71 2 com.apple.ColorSync 0x00007fff93571b69 AppleCMMCreateTransformProperty + 174 3 com.apple.CoreGraphics 0x00007fff93efc8bd __get_full_conversion_code_fragment_block_invoke + 97 4 libdispatch.dylib 0x00007fff9c52b40b _dispatch_client_callout + 8 5 libdispatch.dylib 0x00007fff9c52b303 dispatch_once_f + 67 6 com.apple.CoreGraphics 0x00007fff93efc55a convert_icc + 2557 7 com.apple.CoreGraphics 0x00007fff93efbb4e CGCMSConverterConvertData + 91 8 com.apple.CoreGraphics 0x00007fff93f28b88 CGColorTransformConvertData + 381 9 com.apple.CoreGraphics 0x00007fff93f1d9ca img_colormatch_read + 582 10 com.apple.CoreGraphics 0x00007fff93f1b837 img_data_lock + 8852 11 com.apple.CoreGraphics 0x00007fff93f186c7 CGSImageDataLock + 151 12 libRIP.A.dylib 0x00007fff933ee1d4 ripc_AcquireImage + 972 13 libRIP.A.dylib 0x00007fff933ecc7e ripc_DrawImage + 1011 14 com.apple.CoreGraphics 0x00007fff93f17c48 CGContextDrawImageWithOptions + 571 15 com.apple.CoreGraphics 0x00007fff93f179f1 CGContextDrawImage + 51 16 com.apple.ImageIO.framework 0x00007fff8d31579e CGImageCreateCopyWithParametersNew + 2575 17 com.apple.ImageIO.framework 0x00007fff8d314b95 CGImageSourceCreateThumbnailAtIndex + 3821 18 com.apple.imageKit 0x00007fff8b1ce044 -[IKImageContentView _newCGImageFromImgSrc:index:displayProperties:imageScale:createBitmapImmediately:] + 747 19 com.apple.imageKit 0x00007fff8b1ce49c __69-[IKImageContentView setImageURL:imageAtIndex:withDisplayProperties:]_block_invoke + 57 20 com.apple.imageKit 0x00007fff8b1ce883 __69-[IKImageContentView setImageURL:imageAtIndex:withDisplayProperties:]_block_invoke290 + 21 21 libdispatch.dylib 0x00007fff9c53693d _dispatch_call_block_and_release + 12 22 libdispatch.dylib 0x00007fff9c52b40b _dispatch_client_callout + 8 23 libdispatch.dylib 0x00007fff9c52f29b _dispatch_root_queue_drain + 1890 24 libdispatch.dylib 0x00007fff9c52eb00 _dispatch_worker_thread3 + 91 25 libsystem_pthread.dylib 0x00007fff911764de _pthread_wqthread + 1129 26 libsystem_pthread.dylib 0x00007fff91174341 start_wqthread + 13 --- exception=EXC_BAD_ACCESS:signal=11:is_exploitable=yes:instruction_disassembly=call *CONSTANT(%rax):instruction_address=0x00007fff9357070f:access_type=exec:access_address=0x0000000000000000: The exception code indicates that the access address was invalid in the 64-bit ABI (it was > 0x0000800000000000). Crash accessing invalid address. Consider running it again with libgmalloc(3) to see if the log changes. + EXIT_VALUE=111 ``` ### TIMELINE * 2016-05-17 - Vendor Disclosure * 2016-07-18 - Public Release
idSSV:96729
last seen2017-11-19
modified2017-10-17
published2017-10-17
reporterRoot
titleApple Image I/O API Tiled TIFF Remote Code Execution Vulnerability(CVE-2016-4631)

Talos

idTALOS-2016-0171
last seen2019-05-29
published2016-07-18
reporterTalos Intelligence
sourcehttp://www.talosintelligence.com/vulnerability_reports/TALOS-2016-0171
titleApple Image I/O API Tiled TIFF Remote Code Execution Vulnerability

The Hacker News

idTHN:E0AF6C382BD287E05D4AE838AED49209
last seen2018-01-27
modified2016-07-20
published2016-07-20
reporterMohit Kumar
sourcehttps://thehackernews.com/2016/07/iphone-hack-exploit.html
titleBeware! Your iPhone Can Be Hacked Remotely With Just A Message

References