ziVA: Zimperium’s iOS Video Audio Kernel Exploit

For those of you who are not interested in iOS research and would like to protect themselves against these vulnerabilities, we urge you to update your iOS device to the latest version. Without an advanced mobile security and mitigation solution on the device (such as Zimperium zIPS), there’s little chance a user would notice any malicious or abnormal activity.

The POC is released for educational purposes and evaluation by IT Administrators and Pentesters alike, and should not be used in any unintended way.

The CVEs explanations, as written by Apple, can be found here.

iOS vulnerabilities discovered and reported to Apple

AVEVideoEncoder

Available for: iPhone 5 and later, iPad 4th generation and later, and iPod touch 6th generation

Impact: An application may be able to gain kernel privileges

Description: Multiple memory corruption issues were addressed with improved memory handling.

• CVE-2017-6989: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6994: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6995: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6996: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6997: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6998: Adam Donenfeld (@doadam) of the Zimperium zLabs Team
• CVE-2017-6999: Adam Donenfeld (@doadam) of the Zimperium zLabs Team

IOSurface

Available for: iPhone 5 and later, iPad 4th generation and later, and iPod touch 6th generation

Impact: An application may be able to gain kernel privileges

Description: A race condition was addressed through improved locking.

CVE-2017-6979: Adam Donenfeld (@doadam) of the Zimperium zLabs Team

I will provide an in depth analysis of the vulnerabilities and exploitation techniques at HITBGSEC. After the conference, I will publish the rest of the disclosures as well as my slides and whitepaper.

A brief description of one of the vulnerabilities, CVE-2017-6979:

The function IOSurfaceRoot::createSurface is responsible for the creation of the IOSurface object. It receives an OSDictionary, which it forwards to the function IOSurface::init.
IOSurface::init parses the properties and in case one of these are invalid (e.g, a width that exceeds 32 bits), returns 0, and the creation of the IOSurface is halted.

The IOSurfaceRoot object must hold a lock while calling IOSurface::init because IOSurface::init adds the IOSurface object to the IOSurfaceRoot’s list of surfaces.

Here’s the code that used to call IOSurface::init before Apple’s fix:

In case the IOSurface::init function fails, IORecursiveLockUnlock will be called.
A bogus IOSurface object will still be in the system and in the IOSurfaceRoot’s list of surfaces (thus accessible to everyone).

At this particular moment, an attacker can increase the refcount of the IOSurface(creating, for instance, an IOSurfaceSendRight object attached to the surface) and prevent the bogus IOSurface object from being destroyed.

This leads to the creation and existence of an IOSurface in the kernel which the attacker controls its properties (IOSurface->width = -1 for example).

Such an IOSurface object can be given to other mechanisms in the kernel which might rely on a valid width/height/one of the properties to work, thus causing heap overflows/other problems that might lead to an elevation of privileges by the attacker.

Our proposed solution to Apple was to call IOSurface::release while the lock provider->iosurface_array_lock is still held. Therefore moving the IORecursiveLockUnlock call just below IOSurface::release and putting it after the entire if statement would fix the problem because the IOSurfaceRoot’s list of surfaces will only be available once the bogus IOSurface is already cleaned up.

Further reverse engineering of the function reveals that Apple changed the code according to our suggestions:

The issues are severe and could lead to a full device compromise. The vulnerabilities ultimately lead to an attacker with initial code execution to fully control any iOS device on the market prior to version 10.3.2.
Fortunately, we responsibly disclosed these bugs to Apple and a proper fix was coordinated. iOS users that update their device to the latest iOS version should be protected.

We discovered more vulnerabilities, and the written exploit POC didn’t take advantage of CVE-2017-6979! The vulnerabilities used for the POC will be covered in depth. We plan to release the security advisories as we sent them to Apple right after my talk at HITBGSEC

Zimperium’s patented machine-learning technology, z9, detects the exploitation of this vulnerability. We recommend to strengthen iOS security using a solution like Zimperium zIPS. Powered by z9, zIPS offers protection against known and unknown threats targeting Apple iOS and Google Android devices. z9 has detected every discovered exploit over the last five years without requiring updates.

Source:https://blog.zimperium.com/ziva-video-audio-ios-kernel-exploit/

WinRAR and ZIP File Exploits: This ZIP File Hack Could Let Malware Bypass Your Antivirus

5 Techniques Hackers Use to Jailbreak ChatGPT, Gemini, and Copilot AI systems

This Hacker Toolkit Can Breach Any Air-Gapped System – Here’s How It Works

Hacking Pagers to Explosions: Israel’s Covert Cyber-Physical Sabotage Operation Against Hezbollah!

Five Techniques for Bypassing Microsoft SmartScreen and Smart App Control (SAC) to Run Malware in Windows

How Millions of Phishing Emails were Sent from Trusted Domains: EchoSpoofing Explained

How to implement Principle of Least Privilege(Cloud Security) in AWS, Azure, and GCP cloud

The 11 Essential Falco Cloud Security Rules for Securing Containerized Applications at No Cost

Alisa Esage G

Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.