Monday, March 17, 2025
Homecyber securitymacOS NULL Pointer Dereference Vulnerability Allow Attackers Exploits Kernel

macOS NULL Pointer Dereference Vulnerability Allow Attackers Exploits Kernel

Published on

SIEM as a Service

Follow Us on Google News

Historically, NULL pointer dereferences have been a significant vulnerability in operating systems, including macOS.

These occur when software attempts to access memory at address 0 via a NULL pointer, leading to potential crashes or, under certain conditions, exploitation by attackers.

In the past, attackers could exploit such vulnerabilities by mapping controlled memory at address 0, allowing them to execute arbitrary code in kernel mode.

Historical Exploitation Techniques

In older macOS versions, particularly on Intel architectures, attackers exploited NULL pointer dereferences by mapping fake objects at the NULL address in user space.

NULL Pointer
NULL Pointer Dereferences on Apple Silicon

This was possible with 32-bit binaries, where the page-zero reservation could be disabled, allowing memory allocation at address 0.

Notable examples include Piotr Bania’s exploit of an Intel graphics driver bug in 2016 and Luca Todesco’s “tpwn” exploit in 2015, which targeted OS X Yosemite.

According to Afine Report, these exploits often required bypassing protections like SMEP (Supervisor Mode Execution Prevention), which prevents the kernel from executing user-space memory.

However, Apple has significantly hardened macOS against such exploits.

Starting with OS X 10.11 (El Capitan), Apple introduced SMEP and other hardening measures, including System Integrity Protection (SIP).

By late 2016, Apple had effectively closed avenues for exploiting NULL pointer dereferences by adding NULL checks and improving state handling.

The removal of 32-bit process support in macOS 10.15 further eliminated the primary method for mapping the NULL page on Intel-based machines.

Modern Mitigations on Apple Silicon

The transition to Apple Silicon (ARM64 architecture) has introduced robust mitigations that render NULL pointer dereferences unexploitable.

On Apple Silicon, all user processes are 64-bit, and the kernel enforces strict NULL page mapping protections, ensuring that no memory is mapped at address 0 in user space.

The ARM64 architecture leverages features like Privileged Execute Never (PXN) and Privileged Access Never (PAN), which prevent the kernel from executing code from user-space pages and accessing user memory without explicit overrides.

NULL Pointer
Pointer Authentication Codes (PAC)

Additionally, Pointer Authentication Codes (PAC) on ARM64e architecture protect against pointer corruption by verifying cryptographic signatures on pointer values.

These enhancements make it extremely difficult for attackers to exploit NULL pointer dereferences on modern macOS systems.

Any attempt to do so would result in a fault rather than code execution, effectively halting potential exploits.

Are you from SOC/DFIR Teams? – Analyse Malware Incidents & get live Access with ANY.RUN -> Start Now for Free.

Aman Mishra
Aman Mishra
Aman Mishra is a Security and privacy Reporter covering various data breach, cyber crime, malware, & vulnerability.

Latest articles

Hackers Rapidly Adopt ClickFix Technique for Sophisticated Attacks

In recent months, a sophisticated social engineering technique known as ClickFix has gained significant...

Supply Chain Attack Targets 23,000 GitHub Repositories

A critical security incident has been uncovered involving the popular GitHub Action tj-actions/changed-files, which...

Beware! Malware Hidden in Free Word-to-PDF Converters

The FBI has issued a warning about a growing threat involving free file conversion...

MassJacker Clipper Malware Targets Users Installing Pirated Software

A recent investigation has uncovered previously unknown cryptojacking malware, dubbed MassJacker, which primarily targets...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

Hackers Rapidly Adopt ClickFix Technique for Sophisticated Attacks

In recent months, a sophisticated social engineering technique known as ClickFix has gained significant...

Supply Chain Attack Targets 23,000 GitHub Repositories

A critical security incident has been uncovered involving the popular GitHub Action tj-actions/changed-files, which...

Beware! Malware Hidden in Free Word-to-PDF Converters

The FBI has issued a warning about a growing threat involving free file conversion...