Multimedia processing components are one of today’s most dangerous attack surfaces in any operating system.

When it comes to managing multimedia files, all operating systems work the same. Any new multimedia file — image, audio, video — that reaches a device is automatically transferred to a local OS library that parses the file to know what it is and what to do with it next.

From an attacker’s perspective, bugs in multimedia processing components are the ideal attack surface, as they don’t need any user interaction before having the ability to run code on a remote device/OS.

All an attacker has to do is find a way to send a malformed multimedia file to a device, wait until the file is processed, and until the exploit code triggers.

In today’s interconnected world, exchanging images and videos is one of the most common user interactions. As such, hiding malicious code inside an image sent via SMS, email, or chat (IM) message is an easy way to attack targets without raising signs of alarm.

Due to all these reasons, vulnerabilities in multimedia processing components are currently one of the most sought-after security flaws, as they allow a silent, zero-click, no-user interaction intrusion vector.

Google’s Image I/O research

In a report published today, Project Zero, Google’s elite bug-hunting team, said they looked at one of Apple’s multimedia processing components, which is most likely to be an attractive attack surface for any threat actor needing a way to silently hack an Apple user.

More specifically, Project Zero researchers looked at Image I/O, a framework that’s built into all Apple operating systems and is tasked with parsing and working with image files.

The framework ships with iOS, macOS, tvOS, and watchOS, and most apps running on these operating systems rely on it to process image metadata.

Because of its central role all over the Apple app ecosystem, Image I/O is a dangerous attack surface that inherently enables a zero-click intrusion vector for any attacker, and needs to be as secure as possible against exploits.

Fuzzing Image I/O finds six bugs + eight more

The Project Zero team said they used a technique called “fuzzing” to test how Image I/O handled malformed image files.

The fuzzing process fed Image I/O unexpected input in order to detect abnormalities and potential entry points for future attacks in the framework’s code.

Researchers said they identified six vulnerabilities in Image I/O [1, 2, 3, 4, 5, 6], and another eight in OpenEXR, an open-source library for parsing EXR image files that ships as a third-party component with Image I/O.

Google said that neither of the bugs and the proof-of-concept code that they developed could be used to take over devices, but they didn’t look into the matter, as this wasn’t the purpose of their work.

“It is likely that, given enough effort (and exploit attempts granted due to automatically restarting services), some of the found vulnerabilities can be exploited for RCE [remote code execution] in a 0click attack scenario,” said Samuel Groß, a security researcher with the Project Zero team.

The research team said all the bugs are now fixed. The six Image I/O issues, received security updates in January and April, while the OpenEXR bugs were patched in v2.4.1.

More research needed into Apple’s zero-click attack surface

However, Groß says his team’s findings should merely be the beginning of more research into Image I/O and the rest of Apple’s image and multimedia processing components, all of which are an attractive click attack surface for developing potential zero-click attacks against Apple users and devices.

Groß says that the first step that Apple should take going forward is to continue his research on fuzzing the Image I/O code, since his work was most likely incomplete due to a lack of visibility and access to the framework’s source code.

“Thorough fuzzing, in any case, is always best performed by the maintainers with source code access,” Groß said.

In the long term, more complex mitigation solutions can also be enforced. Groß says that the simplest is to give app developers the ability to restrict the type of image formats that can be processed through their apps via Image I/O, a security feature that would prevent exotic image file formats from delivering malicious code to Image I/O in the first place.

In the long run, Apple should also look into bolstering its other multimedia processing components, similar to how Google and Mozilla have done for Android and Firefox, respectively.

For example, after the discovery of the Stagefright vulnerability, Google split the MediaServer component into smaller libraries, protected by different access permissions, making full device compromises harder to achieve.

Similarly, when Mozilla began integrating Rust code inside Firefox, the first component it re-wrote in its security-first programming language was its multimedia processing stack, showing exactly how important the component was to Firefox’s entire security model.

With the number of spyware and surveillance software vendors increasing all over the world, many of these companies are now looking at easy ways of breaching Apple systems, and, for the time being, multimedia processing libraries offer the most obvious way in. However, this way in shouldn’t be easy.