Talos Vulnerability Report

TALOS-2017-0275

Apple GarageBand Out of Bounds Write Code Execution Vulnerability

February 14, 2017

CVE Number

CVE-2017-2374

Summary

An exploitable out of bounds write vulnerability exists in the parsing of saved files in Apple's GarageBand version 10.1.5. A specially crafted project file can cause an out of bounds write resulting in an exploitable condition. An attacker can deliver a project file via other means. This vulnerability is the result of an incomplete fix of bug id TALOS-2016-0262 / CVE-2017-2372.

Tested Versions

Apple GarageBand 10.1.5

Product URLs

CVSSv3 Score

8.8 -- CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-123: Write-what-where Condition

Details

Garageband is a music creation tool used to create new and original music easily from your computer. GarageBand comes installed for free with all new Mac purchases, meaning there is a large market of people who have this software installed on there computer. The file format used by GarageBand is a proprietary .band file. There exists a vulnerability in the parsing of this format. The format is broken into various segments each with its own properties. This length is controllable by the user and no validation checks are done to ensure this length is in bounds thus leading to an exploitable condition. This vulnerability is due to an incomplete fix of TALOS-2016-0262 / CVE-2017-2372. The code that contains the vulnerability is used for serialization of a string and arises in multiple areas when parsing the format.

Shown above we can see a null byte being written out of bounds due to an invalid calculation of R14 and RCX. Looking through the current function we can see where these values come from. Starting with R14 it can be seen that this is a buffer on the heap. We run malloc history on it and the output is shown below:

At, [2], we can see var_12 being loaded into ECX only a few lines above our vulnerability. looking further we see this same variable, [0], passed in as the second argument to a dynamic function call. Tracing our input further, we follow it into the dynamic call below:

As can be seen,[0], our buffer is moved into R14. It is then zeroed out, moved into the 4th argument, [1], for CFDataGetBytes,[2]. This function gets data from a buffer for a range, designated by RSI and EDX, and stores it into RCX. In this case the range it is extracting is 2 bytes. This extracted data is then used in our original calculation above to index into the original data buffer. The problem arises in the fact that the buffer that data being is extracted from, [2], is user controlled and no input validation is done on the bytes read in. This means that RCX is user controlled and can be any arbitrary 2 byte value. This leads to an exploitable null byte write anywhere.

It was originally believed that only this particular structure led to this code path. Upon receiving Apple's update it is now apparent that there are multiple different structures utilizing the same parsing code. The code the crash is in is responsible for serializing a string and is used relatively frequently allowing this vulnerability to arise again.