Inspired by Kevin Backhouse’s great work on finding XNU remote vulnerabilities I decided to spend some time looking at CodeQL and performing some variant analysis. This lead to the discovery of a local root to kernel (although documented by Apple as remote) vulnerability within the 6LowPAN code of macOS 10.15.4.

Recently I had the need to explore coverage guided fuzzing in Go. Whilst there is a bit of information scattered around on multiple different sites, as someone who is fairly new to Go, I couldn’t find a good concise source of information on what is already out there and the current state of play of fuzzer tooling within the Go world.

In my previous blog post I dug into a general overview of the KASAN implementation in XNU. This post goes more in depth in detecting kernel uninitialized information leaks using it (no 0days dropped here :)). Kernel Information Leaks to userland are a common problem and can be used to leak confidential information or disclose kernel memory addresses which are typically used to bypass KASLR. An example of this type of vulnerability is CVE-2017-13868.

In order to learn about serverless architecture, I experimented with implementing a quick proof of concept crash triaging tool using AWS Lambda Functions. There are many benefits of serverless architecture when you really don’t want to manage underlying infrastructure components and often cost saving advantages which can be made. These concepts lend themselves well to certain components of a continuous fuzzing architecture (such as Google’s Clusterfuzz).

Recently Apple patched a vulnerability (CVE-2020-3919) in IOHIDFamily in their security update 10.15.4 which may allow a malicious application to execute arbitrary code with kernel privileges. It turns out this bug also affected iOS too.

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.