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.