Apple patches malicious exploit found in GarageBand for Mac project files
The latest patch for GarageBand for the Mac fixes a vulnerability in the music creation software that a security researcher claims could be exploited by an attacker, by using malformed project files to execute malicious code.
Bringing GarageBand to version 10.1.6, the patch addresses a single vulnerability discovered by Tyler Bohan of Cisco Talos. Apple's description of the bug advises the opening of a "maliciously crafted" GarageBand project file could lead to "arbitrary code execution," with Apple improving the macOS app's memory handling to eliminate a corruption issue.
According to Bohan, the issue lies in the parsing of the proprietary .band file format. The file is broken up into segments with each having their own properties, though it is noted that the length of each segment is controllable by the user, and no validation attempts are made to check that the length of each segment is within defined bounds.
This lack of verification means an attacker can create a .band file with hidden code, which can execute once the file is opened within GarageBand.
Bohan in fact discovered two vulnerabilities in GarageBand, with a similar validation issue partially fixed in an earlier 10.1.5 patch. The latest vulnerability stems from this incomplete fix, which has been solved with Tuesday's patch release.
It is unlikely that either vulnerability has been used in the wild, with Bohan disclosing them only after Apple issued a patch for the issues. Due to responsible disclosure procedures, and the need for a potential victim to open the malformed file themselves, it is not believed the vulnerabilities have been used in an attack.
GarageBand 10.1.6 can be downloaded via a Mac App Store update.
Bringing GarageBand to version 10.1.6, the patch addresses a single vulnerability discovered by Tyler Bohan of Cisco Talos. Apple's description of the bug advises the opening of a "maliciously crafted" GarageBand project file could lead to "arbitrary code execution," with Apple improving the macOS app's memory handling to eliminate a corruption issue.
According to Bohan, the issue lies in the parsing of the proprietary .band file format. The file is broken up into segments with each having their own properties, though it is noted that the length of each segment is controllable by the user, and no validation attempts are made to check that the length of each segment is within defined bounds.
This lack of verification means an attacker can create a .band file with hidden code, which can execute once the file is opened within GarageBand.
Bohan in fact discovered two vulnerabilities in GarageBand, with a similar validation issue partially fixed in an earlier 10.1.5 patch. The latest vulnerability stems from this incomplete fix, which has been solved with Tuesday's patch release.
It is unlikely that either vulnerability has been used in the wild, with Bohan disclosing them only after Apple issued a patch for the issues. Due to responsible disclosure procedures, and the need for a potential victim to open the malformed file themselves, it is not believed the vulnerabilities have been used in an attack.
GarageBand 10.1.6 can be downloaded via a Mac App Store update.
Comments
Context-click one one to see its contents.
Put extremely simply, anytime you input a value into a program, whether it's text or numbers or audio or a password or whathaveyou, whatever exceeds the length the program is expecting is truncated and ignored, or will otherwise throw up an error to the user.
If you have an improperly terminated input, where somebody just forgot to account for there being more data than expected and this doesn't happen, whatever data exceeds the limit the program is designed to handle will theoretically DIRECTLY PASS THROUGH THE CPU. If you carefully craft malicious code to exploit just such a hole, you can add your own program to the end of useful and innocuous data, and IT WILL BE EXECUTED BY THE CPU.
So if, for example, the exploit were in a password-entry field, you could exploit the machine by typing the password and then tacking on a whole bunch of executable code to the end of that. Normally, code would be in place to reject that. But if it were forgotten or improperly coded, you could access the machine that way and have it do virtually whatever you wanted (depending upon where in user-/adminspace the program is running). SOME file within the GarageBand package was susceptible to just that kind of attack.