In the previous post, we had a crash course on syzkaller, one of the most renowned Linux kernel fuzzers. We explored how to set it up in a non-trivial configuration (on macOS, no lessābut the general steps also apply to Linux, of course), compile the kernel with a vulnerable driver, and configure everything for syzkaller to crash it. Now it’s time to target real-world code. So, what code?
syzkaller is constantly grinding on Google’s servers, relentlessly transforming kilowatts of power into test cases and crashes.
syzkaller is one of the best fuzzers for the Linux kernel. It supports coverage (through KCOV) and provides a way to declaratively describe syscalls you want to fuzz. It also highly encourages you to use KASAN (and you can even use more sanitizers supported by the kernel). We got to know KASAN in the previous post and it’s a really good thing that allows you to catch more bugs during fuzzing.
It all started when I had brain surgery. After several days in the hospital, I got home. But I guess the surgeon hit something in my brain after all because, at home, I started to feel a strong desire to read Linux kernel module code. I decided to start with a 3rd party module that I use, but its usage is not widespread, making it an easier target.
After just a couple of hours, I found something that looked like a vulnerability.
One day, I saw that srelay exists. Itās a pretty old SOCKS4 and SOCKS5 proxy server with the latest update from 2018. Hand on heart, it’s hard to call it popular, but itās far from being dead either. I also wasnāt able to find any information about the history of srelay vulnerabilities. To top it all off, the code base is really compact, so it sounded like a good opportunity to try out some of AFL++’s new features.
When you’re dealing with bare metal firmware, you have access to every bit of code: from the very start of the execution to the very end. Among other things, this means that nothing here comes for granted: all of the CPU subsystems are uninitialized, including the Memory Management Unit (MMU). Even more than that - the MMU may never be initialized over the whole time of execution, depending on your target.
The first step in finding vulnerabilities in some kind of IoT device is getting its firmware. 5-10 years ago, it was extremely easy: firmware of every device was available on the manufacturerās website. And while itās still true in some cases, now thereās no more a one-size-fits-all solution. Now we have several ways of getting firmware, ranging from very easy to very hard.
Download: Very Easy Maybe the manufacturer still offers firmware for download to everyone in need.
Last week marked a very important milestone for me: I conducted my first offline reverse engineering workshop. It took a lot of effort and energy, but it finally happened! I want to express special thanks to my colleagues without whom this couldn’t have happened for the idea, support in organizing and developing the idea further!
My first attempt at this was 4 years and 3 jobs ago and Iām really proud that after all this years, I managed to implement it exactly how I wanted.
1. The Role of NS (Non-Secure) Memory Bits Each memory page in a system comes with a Non-Secure (NS) bit. The “Normal World” can only access memory with the NS bit set, while the “Secure World” has unrestricted access to both NS and Secure memory. The NS bit is crucial for compartmentalizing secure and non-secure operations. Learn more about NS memory.
2. Exception Levels (ELs) ARM CPUs utilize four levels of privileges, known as Exception Levels (ELs).