Full Report
This article will show some initial research into booting a KSAN kernel, testing the KASAN functionality and some initial groundwork on KSANCOV. This functionality is super useful when performing kernel crash triage or fuzzing against macOS.
Analysis Summary
# Research: A brief introduction into KASAN on macOS Catalina
## Metadata
- Authors: Alex Plaskett
- Institution: Random Security Research
- Publication: Blog Post
- Date: February 18, 2020
## Abstract
This initial research explores booting a macOS system with the Kernel Address Sanitizer (KSAN) enabled kernel derived from a publicly released Kernel Debug Kit (KDK). The work demonstrates the methodology for deployment, verification of KASAN functionality through triggering a known error (double free), and outlines the groundwork for enabling Kernel Address Sanitizer Coverage (KSANCOV) for enhanced kernel fuzzing and crash triage on macOS.
## Research Objective
The primary objective of this research was to investigate the feasibility of running and utilizing Apple's kernel-level memory error detection tool, KASAN, on macOS Catalina. A secondary objective was to lay the preliminary foundation for leveraging KSANCOV functionality for security analysis, specifically kernel fuzzing and crash triage.
## Methodology
### Approach
The methodology involved leveraging a specific KDK version (**KDK\_10.15.4\_19E287.kdk**) which contained a pre-compiled KASAN kernel (`kernel.kasan`). The approach required manually replacing the production kernel and system extensions on a target macOS installation (requiring SIP disabling) and modifying boot arguments to load the KASAN-instrumented environment. Verification included checking system outputs (`uname`, `sysctl`) and actively testing the KASAN mechanism.
### Dataset/Environment
The research focused on **macOS Catalina (10.15.x)**, utilizing the **Kernel Debug Kit 10.15.4 build 19E287**. A virtual machine environment was implied for the modifications and testing process.
### Tools & Technologies
- **KSAN (Kernel Address Sanitizer):** Apple's implementation of AddressSanitizer for kernel memory error detection.
- **KDK (Kernel Debug Kit):** Used to obtain pre-compiled kernel and extension binaries.
- **`nvram`:** Used to set custom boot arguments (e.g., `kasan.checks`, `kcsuffix=kasan`).
- **`sysctl`:** Used to check KASAN status (`kern.kasan.available`) and trigger test cases (`kern.kasan.test`).
- **`dwarfdump`:** Used to verify KEXTs were compiled with KASAN by comparing UUIDs.
- **LLDB Macros:** Mentioned as existing tools (`tools/lldbmacros/kasan.py`) for interacting with KASAN.
## Key Findings
### Primary Results
1. **Successful KASAN Boot:** The research successfully demonstrated booting macOS 10.15.x with the `kernel.kasan` binary, confirming KASAN compatibility with the specific KDK version.
2. **KASAN Validation:** KASAN functionality was verified by setting `kern.kasan.test=100` (triggering a double-free test case), which resulted in a kernel panic/crash dump, indicating the memory instrumentation was active.
3. **KASAN State Verification:** The availability and enablement of KASAN were confirmed via `sysctl kern.kasan.available` returning 1.
4. **KEXT Instrumentation Check:** The methodology validated that accompanying KDK KEXTs (like `IOHIDFamily`) were also compiled with KASAN by matching their debug UUIDs against the KDK versions.
5. **KSANCOV Potential:** The presence of the `/dev/ksancov` device interface and related source code (`san/ksan.c`, `san/tools/ksancov.c`) confirms the architectural existence of kernel coverage collection capabilities integrated with KASAN on macOS.
### Novel Contributions
- Practical, step-by-step instructions for deploying a KASAN-instrumented kernel on a production or near-production macOS system using available KDKs, circumventing typical source-build dependency issues.
- Initial analysis confirming the hooks for **KSANCOV**, establishing preliminary groundwork for coverage-guided kernel fuzzing on macOS.
## Technical Details
The deployment required mounting the root volume as writable (`sudo mount -uw /`), copying the necessary binaries (`kernel.kasan` and extensions) to `/System/Library/Kernels/` and `/System/Library/Extensions/`, and using specific boot arguments: `-v keepsyms=1 debug=0x2444 kasan.checks=24576 -zp -zc kcsuffix=kasan`. The kernel version output (`root:xnu_kasan-6153.101.6~12/KASAN_X86_64`) confirms the build context. The KASAN configuration exposes numerous tunable parameters via `sysctl`, covering quarantine size, leak thresholds, and various check types. Furthermore, boot-argument blacklisting (`kasan.bl`) through `PE_parse_boot_arg_str` suggests runtime configuration for excluding specific functions from KASAN checks.
## Practical Implications
### For Security Practitioners
This research provides the immediate prerequisite knowledge for any advanced macOS kernel security researcher to begin memory safety analysis using official tooling hooks provided by Apple. It enables researchers to observe native KASAN crash reports when fuzzing the kernel or analyzing existing vulnerabilities.
### For Defenders
While KASAN is a testing/development tool, the understanding of its functionality and configuration (especially KASAN boot arguments) aids in understanding baseline kernel hardening mechanisms Apple employs for development quality assurance.
### For Researchers
The primary implication is enabling **coverage-guided fuzzing** against the kernel via KSANCOV. Although the KDK binary lacked KSANCOV symbols, knowing the necessary compilation flags (`-fsanitize-coverage=trace-pc-guard`) and required driver API (`open /dev/ksancov`) dictates the necessary steps: compiling XNU from source with these flags enabled.
## Limitations
1. **KSANCOV Inoperability:** The pre-built `kernel.kasan` from the KDK was *not* compiled with KSANCOV support, meaning the coverage collection mechanism could not be tested directly without compiling XNU from source.
2. **Dependency on Specific KDK:** The methods rely heavily on the availability and compatibility of specific KDK builds, which may lag behind or have unique configurations compared to the next public release.
3. **Hacky Boot Procedure:** Deploying the kernel requires disabling System Integrity Protection (SIP) and manual file replacement, which is complex and not viable for mass deployment.
## Comparison to Prior Work
This work is foundational, serving as a "how-to" guide exploiting available Apple debug artifacts (the KDK). It builds upon the general concept of AddressSanitizer (ASAN) by applying it directly to the XNU kernel environment, focusing specifically on the macOS Catalina implementation details revealed through the KDK structure.
## Real-world Applications
- **Kernel Fuzzing:** Utilizing KSANCOV (once built from source) in combination with KASAN to create highly effective, feedback-driven fuzzers for the XNU kernel.
- **Kernel Crash Triage:** Using KASAN reports generated during stability issues to precisely pinpoint the memory corruption trigger rather than relying solely on panic logs.
## Future Work
1. **Build XNU from Source:** Compile the XNU kernel from Apple Open Source components, explicitly enabling KSANCOV instrumentation using the identified CFLAGS (`-fsanitize-coverage=trace-pc-guard`) to operationalize kernel coverage.
2. **Develop KSANCOV Usage:** Implement the userspace API steps (opening `/dev/ksancov`, setting mode, mapping buffer, tracing) to collect and analyze coverage data generated during kernel execution or fuzzing campaigns.
3. **Explore UBSAN:** Further investigation into the configuration and logging mechanism of Apple's Kernel **UBSan** (`kern.ubsan.log`).
## References
- Google Sanitizers Wiki: AddressSanitizer
- Clang Documentation: UndefinedBehaviorSanitizer (UBSan)
- Apple Open Source website (for reference on source visibility)