Earlier this year, I discovered a flaw in XNU, which is the kernel that Apple uses on both macOS and iOS. While it’s not a particularly complicated flaw, I wanted to explain how I discovered it and how it works, both so that I can motivate others and so that they can learn from my discovery. Within the memdev.c file (the ramdisk device driver), I found the source of the vulnerability, which was a write/read operation that exceeded the allowed range. Why are ramdisks such an intriguing target to look at? If you identify a bug in the driver, it may give you the ability to execute code in the kernel. Additionally, on some systems, you may be able to construct ramdisks with particular settings such that it is mapped to physical memory, which may give you the ability to read and write data to physical memory. ...

I imagine we’ve all heard about the recent “Sequoia” bug discovered by the Qualys Research team, identified by CVE-2021-33909. It’s a fascinating bug caused by a size_t to int conversion. According to the analysis, seq_dentry attempts to convert a size_t to an int by sending size_t size to the dentry_path function, which expects a signed integer. Assuming the architecture is 32 bits, size_t’s value can be 0 to 4294967296 since it is unsigned, but int can only hold from -2147483648 to 2147483648 because it is signed (this means that it can have negative values also). This results in an out-of-bounds access during the pointer arithmetic in dentry_path that’s done with p = buf + buflen;. ...

Mistreatment by Apple Security is unfortunately something you’re likely to come across on a regular basis. Usually this concerns people that conduct free work for Apple in their spare time by auditing their assets. Despite Apple’s website claiming the opposite, you’ll frequently find things like quiet patching, no credit, no bounties, and an appalling lack of communication. This is unwise on Apple’s part because it frustrates people who find these bugs and disincentivizes them from sharing them with Apple. Remember, every bug that gets reported to them (instead of being sold to some shady outfit) and that gets fixed subsequently is one that can not be exploited in the future to make your device less safe. The very least they can do to honour the work of independent researchers is to communicate clearly and give them credit where appropriate. ...

Following up on my first blog post, I’ve received a few requests to write about setting up a debugging environment; however, since everybody uses different emulators and so on, I’ll mainly focus on which config options are useful! You must first obtain the kernel sources for your preferred version before you can set up a kernel suitable for debugging. We’ll have to decompress it after that. # use your preferred version $ wget https://git.kernel.org/torvalds/t/linux-5.12-rc5.tar.gz $ tar xvf linux-5.12-rc5.tar.gz After you’ve pulled your source, you’ll need to determine which emulator you’ll use and how you’ll use it. Personally, I prefer QEMU + kvm, but I’ve recently learned about virtme, which is essentially a very useful QEMU wrapper. ...

I’m writing this post because I often hear that kernel exploitation is intimidating or difficult to learn. As a result, I’ve decided to start a series of basic bugs and exercises to get you started! Prerequisites Knowledge of the Linux command line Knowing how to read and write basic C may be beneficial Being able to debug with the help of a virtual computer or another system Able to install the kernel module compilation build requirements A basic understanding of the difference between userland and kernelland could be helpful Having a basic understanding of assembly can be beneficial for future episodes For this part, I wrote a simple Linux character device, /dev/shell. This driver will take two arguments, uid and cmd, and it will execute the cmd command as the specified uid. To understand how this driver works, I’ll explain a few things! ...