Apple patches malicious exploit found in GarageBand for Mac project files

AppleInsider

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.

Rayz2016

Did he have a working test case for this or was it all theoretical? In either case, good job. He gave Apple a chance to patch it before disclosing to everyone else. 

dysamoria

How does an audio file length mismatch enable code execution?

MplsP

dysamoria said:

How does an audio file length mismatch enable code execution?

This is my question, too. I just figured The garage band file was a data file, so I'm no sure how code would be executed by garage band accessing the file.

Rayz2016

dysamoria said:

How does an audio file length mismatch enable code execution?

Yes, that's what I was thinking. Has he managed to actually do this in practice?

spheric

.band "files" are packages (folders).  

Context-click one one to see its contents. 

MplsP

spheric said:

.band "files" are packages (folders).  

Context-click one one to see its contents. 

Yeah, I get that, but my admittedly limited understanding of how this works with OS X is that when you double click on the file, it opens the associated program which in turn opens the file that you clicked on, similar to opening the program and selecting File -> open. If the package contains an executable, why would GarageBand do anything with it?

spheric

MplsP said:

spheric said:

.band "files" are packages (folders).  

Context-click one one to see its contents. 

Yeah, I get that, but my admittedly limited understanding of how this works with OS X is that when you double click on the file, it opens the associated program which in turn opens the file that you clicked on, similar to opening the program and selecting File -> open. If the package contains an executable, why would GarageBand do anything with it?

The point is the same as with every buffer overrun exploit: 

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. 

dysamoria

spheric said:

MplsP said:

spheric said:

.band "files" are packages (folders).  

Context-click one one to see its contents. 

Yeah, I get that, but my admittedly limited understanding of how this works with OS X is that when you double click on the file, it opens the associated program which in turn opens the file that you clicked on, similar to opening the program and selecting File -> open. If the package contains an executable, why would GarageBand do anything with it?

The point is the same as with every buffer overrun exploit: 

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. 

So there's nothing special about executables vs data files? So long as the binary is passed through the CPU, the instructions it contains (or not) are executed?

spheric

Please don't ask me about details. IANAD — that rudimentary explanation up there is about as far as my understanding goes.