Security researcher Sönke Huster has found five security holes in the Linux kernel. In an interview with us, he reveals how he did it.
Sönke Huster is a research associate at the Secure Mobile Networking Lab (SEEMOO) at TU Darmstadt.
In August 2022, he discovered five vulnerabilities in the Linux kernel’s WLAN stack. There are now patches.
c’t 2/2023 )
Is your Windows having problems? With the c’t-Notfall-Windows in the 2/2023 edition, you create a bootable USB stick that tackles viruses, saves data and solves boot problems. Is your smart home too talkative and the mandatory cloud connection is annoying? We looked at open source solutions to free your hardware. We also tested 25 routers for IPv6 compatibility, set up our own mastodon instance and looked at how Windows on ARM is actually doing. You can read all this and much more in c’t 2/2023.
We spoke to him about the find, its methodology and the disclosure process.
c’t: What makes you look for security vulnerabilities in the Linux kernel?
Sonke Huster: In 2022 I wrote my master’s thesis on Bluetooth fuzzing under Linux. The idea came from my master thesis supervisor Dr. Jiska Classen. I also found a few small security gaps in the Bluetooth stack. Then I became a research associate at Prof. Matthias Hollick’s Secure Mobile Networking Lab and it made sense to extend it to WiFi. From an attacker’s point of view, WLAN and Bluetooth are super interesting and somehow similar. If I want to hack you, it’s much cooler, I can do it through the air from the room next door without having to physically access your computer first, for example to plug in a USB stick. Both protocols are predestined for this.
c’t: You found five vulnerabilities in the Linux kernel. How did you go about it?
cough: The method I use is called fuzzing. She was created by Barton Miller in the 1980s [Professor der Informatik in Madison, Wisconsin, Anm. d. Red.] discovered logging into his work computer remotely via a telephone line on wooden poles. During thunderstorms, the transmission of the signal was disrupted and his input was distorted. This resulted in programs crashing or behaving differently than expected. This is how they found out that random inputs could be used to find bugs and security gaps, and fuzzing – also known as fuzz testing – was invented. Today, so-called fuzzers are used for this purpose. These are basically programs that flood the input interfaces of programs, operating systems or networks with random data.
However, one no longer works with completely random inputs. You can refine the process and use inputs that are close to what the target – in this case Linux in my VM – expects. To examine WLAN, I let the fuzzer send WLAN packets with small anomalies to the Linux system in my virtual machine, which it constantly modifies. The fuzzer observes and documents which code in the kernel is triggered to process the mutated WLAN packets. You could also say: Which path a packet takes during processing. Whenever code has been covered in the processing of a packet that has not previously been executed, the fuzzer includes that packet in its input set and uses it as a starting point for new mutations. It then sends these modified packets back to the kernel. This all happens a few thousand times a second. The aim is to “cover” as much code as possible, i.e. to cover parts of the kernel code with the mutated inputs that the fuzzer does not yet know. Coverage-guided mutational fuzzing is the technical term for this type of fuzz testing.
c’t: If the target crashes, did you land a hit?
cough: I agree. A crash or other unexpected behavior, such as hanging, is almost always an indication of a bug or vulnerability. The fuzzer saves the entries that cause something like this separately so that I can reproduce the crash. For example, in one of the five vulnerabilities I found, a broken package—or a series of packages—corrupted a so-called linked list, effectively pointing the last package in the list back to the first. During processing, the operating system never knew when the list was over and ended up hanging because it couldn’t get out of this loop.
c’t: That sounds like an annoying bug, but not one that an attacker could exploit for remote code execution.
cough: no It would be difficult to find a way to exploit that. The infinite loop causes the operating system to hang and that’s it. But another of the vulnerabilities allows an attacker to overwrite the memory, theoretically allowing them to run code remotely. The kernel reserves memory for running programs and processes. If, for example, 128 bytes are provided at a point in memory for a specific process, then you shouldn’t actually write more than these 128 bytes. Certain inputs of the fuzzer have revealed errors in the packet processing that lead to the fact that one can write more than the intended length in a part of the memory reserved for a process – a so-called buffer overflow.
c’t: That would already be enough for an attacker to be able to take over a computer remotely?
cough: Theoretically. It was possible for an attacker to write 256 bytes in a controlled manner to the memory area following the allocated one. For an RCE, one would also have to find out where in memory the broken WLAN packets that trigger this error in the kernel code are processed at all. But that’s not so easy, because there are mechanisms that ensure that the kernel is always executed at different locations in memory. It’s called Kernel Address Space Layout Randomization. But it’s conceivable that other security vulnerabilities would reveal this.
c’t: Is that a hypothesis or were you able to test it successfully?
cough: no That’s beyond my abilities. It’s more of a hypothesis. But one that is very likely to be true. There are different types of security vulnerabilities and a vulnerability of this type – in this specific case in combination with others – is theoretically suitable for this.
From the attacker’s point of view, the exciting thing about the security gaps is that you don’t need any user interaction at all. You don’t have to accidentally connect to a hotspot that the hacker controls to send you nasty WiFi packets. It is enough if you have your WLAN on and your device searches for networks in the area. This happens relatively often in the background to determine the location. It’s not like a phishing attempt, where the attacker has to get the victim to click a button and enter login credentials. This is precisely what makes such gaps potentially so critical. There aren’t that many Linux users, but three of the vulnerabilities affect Android, and Android users are plentiful. Most users usually have their Wi-Fi on on their smartphones.
c’t: Is the fuzzer an in-house development of the Secure Mobile Networking Labs?
cough: Yes. We use components from LibAFL. This is a library that comes with a very good framework, but the architecture of our fuzzer is very different from that of existing fuzzers.
