In April of this year, FreeBSD patched a 13-year-old heap overflow in the Wi-Fi stack that could allow network-adjacent attackers to execute arbitrary code on affected installations of FreeBSD Kernel. This bug was originally reported to the ZDI program by a researcher known as m00nbsd and patched in April 2022 as FreeBSD-SA-22:07.wifi_meshid. The researcher has graciously provided this detailed write-up of the vulnerability and a proof-of-concept exploit demonstrating the bug.

Our goal is to achieve kernel remote code execution on a target FreeBSD system using a heap overflow vulnerability in the Wi-Fi stack of the FreeBSD kernel. This vulnerability has been assigned CVE-2022-23088 and affects all FreeBSD versions since 2009, along with many FreeBSD derivatives such as pfSense and OPNsense. It was patched by the FreeBSD project in April 2022.

The Vulnerability

When a system is scanning for available Wi-Fi networks, it listens for management frames that are emitted by Wi-Fi access points in its vicinity. There are several types of management frames, but we are interested in only one: the beacon management subtype. A beacon frame has the following format:

In FreeBSD, beacon frames are parsed in ieee80211_parse_beacon(). This function iterates over the sequence of options in the frame and keeps pointers to the options it will use later.

One option, IEEE80211_ELEMID_MESHID, is particularly interesting:

There is no sanity check performed on the option length (frm[1]). Later, in function sta_add(), there is a memcpy that takes this option length as size argument and a fixed-size buffer as destination:

Due to the lack of a sanity check on the option length, there is an ideal buffer overflow condition here: the attacker can control both the size of the overflow (sp->meshid[1]) as well as the contents that will be written (sp->meshid).

Therefore, when a FreeBSD system is scanning for available networks, an attacker can trigger a kernel heap overflow by sending a beacon frame that has an oversized IEEE80211_ELEMID_MESHID option.

Building a “Write-What-Where” Primitive

Let’s look at ise->se_meshid, the buffer that is overflown during the memcpy. It is defined in the ieee80211_scan_entry structure:

Here, the overflow of se_meshid allows us to overwrite the se_ies field that follows. The se_ies field is of type struct ieee80211_ies, defined as follows:

We will be interested in overwriting the last two fields: data and len.

Back in sta_add(), not long after the memcpy, there is a function call that uses the se_ies field:

This ieee80211_ies_init() function is defined as:

The data parameter here points to the beginning of the beacon options in the frame, and len is the full length of all the beacon options. In other words, the (data,len) couple describes the options buffer that is part of the frame that the attacker sent:

As noted in the code snippet, the ies structure is fully attacker-controlled thanks to the buffer overflow.

Therefore, at $1:

       -- We can control len, given that this is the full size of the options buffer, and we can decide that size by just adding or removing options to our frame.
       -- We can control the contents of data, given that this is the contents of the options buffer.
       -- We can control the ies->data pointer, by overflowing into it.

We thus have a near-perfect write-what-where primitive that allows us to write almost whatever data we want at whatever kernel memory address we want just by sending one beacon frame that has an oversized MeshId option.

Constraints on the Primitive

A few constraints apply to the primitive:

1. The FreeBSD kernel expects there to be SSID and Rates options in the frame. That means that there are 2x2=4 bytes of the options buffer that we cannot control. In addition, our oversized MeshId option has a 2-byte header, so that makes 6 bytes we cannot control. For convenience and simplicity, we will place these bytes at the beginning of the options buffer.

2. Our oversized MeshId option must be large enough to overwrite up to the ies->data and ies->len fields, but not more. This equates to a length of 182 bytes for the MeshId option, plus its 2-byte header. To accommodate the MeshId option plus the two options mentioned above, we will use an options buffer of size 188 bytes.

3. The ies->data and ies->len fields we overwrite are respectively the last 8 and 4 bytes within the options buffer, so they too are constrained.

4. The ies->len field must be equal to len for the branch at $0 not to be taken.

The big picture of what the frame looks like given the aforementioned constraints:

Maintaining stability of the target

Let’s say we send a beacon frame that uses the primitive to overwrite an area of kernel memory. There is going to be a problem at some point when the kernel subsequently tries to free ies->data. This is because ies->data is supposed to point to a malloc-allocated buffer, which may no longer be true after our overwrite.

To maintain stability and avoid crashing the target, we can send a second, corrective beacon frame that overflows ies->data to be NULL and ies->len to be 0. After that, when the kernel attempts to free ies->data, it will see that the pointer is NULL, and won’t do anything as a result. This allows us to maintain the stability of the target and ensure our primitive doesn’t crash it.

Choosing what to write, and where to write it

Now we have a nice write-what-where primitive that we can invoke with just one beacon frame plus one corrective frame. What exactly can we do with it now?

A first thought might be to use the primitive to overwrite the instructions that the kernel executes in memory. (Un)fortunately, in FreeBSD, the kernel text segment is not writable, so we cannot use our primitive to directly overwrite kernel instructions. Furthermore, the kernel implements W^X, so no writable pages are executable.

However, the page tables that map executable pages are writable.

Injecting an implant

Here we are going to inject an implant into the target's kernel that will process "commands" that we send to it later on via subsequent Wi-Fi frames — a full kernel backdoor, if you will.

The process of injecting this implant will take four beacon frames.

This is a bit of a bumpy technical ride, so fasten your seatbelt.

Frame 1: Injecting the payload

Background: the direct map is a special kernel memory region that contiguously maps the entire physical memory of the system as writable pages, except for the physical pages of read-only text segments.

We use the primitive to write data at the physical address 0x1000 using the direct map:

0x1000 was chosen as a convenient physical address because it is unused. The data we write is as follows:

The implant shellcode area contains the instructions of our implant. The rest of the fields are explained below.

Frame 2: Overwriting an L3 PTE

Quick Background: x64 CPUs use page tables to map virtual addresses to physical RAM pages, in a 4-level hierarchy that goes from L4 (root) to L0 (leaf). Refer to the official AMD and Intel specifications for more details.

In this step, we use the primitive to overwrite an L3 page table entry (PTE) and make it point to the L2 PTE that we wrote at physical address 0x1000 as part of Frame 1. We crafted that L2 PTE precisely to point to our three L1 PTEs, which themselves point to two different areas: (1) two physical pages of the kernel text segment, and (2) our implant shellcode.

In other words, by overwriting an L3 PTE, we create a branch in the page tables that maps two pages of kernel text as writable and our shellcode as executable:

At this point, our shellcode is mapped into the target’s virtual memory space and is ready to be executed. We will see below why we're mapping the two pages of the kernel text segment.

The attentive reader may be concerned about the constraints of the primitive here. Nothing to worry about: the L3 PTE space is mostly unpopulated. We just have to choose an unpopulated range where overwriting 188 bytes will not matter.

Frame 3: Patching the text segment

In order to jump into our newly mapped shellcode, we will patch the beginning of the sta_input() function in the text segment. This function is part of the Wi-Fi stack and gets called each time the kernel receives a Wi-Fi frame, so it seems like the perfect place to invoke our implant.

How can we patch it, given that the kernel text segment is not writable? By mapping as writable the text pages that contain the function. This is what we did in frames 1 and 2, with the first two L1 PTEs, that now give us a writable view of the instruction bytes of sta_input():

Back on topic, we use the primitive to patch the first bytes of sta_input() via the writable view we created in frames 1 and 2, and replace these bytes with:

This simply calls our shellcode. However, the constraints of our primitive come into play:

1. The first constraint of the primitive is that the first 6 bytes that we overwrite cannot be controlled. Overwriting memory at sta_input would not be great, as it would put 6 bytes of garbage at the beginning of the function, causing the target to crash.

However, if we look at the instruction dump of sta_input, we can see that it actually has a convenient layout:

What we can do here is overwrite memory at sta_input-6. The 6 bytes of garbage will just overwrite the unreachable NOPs of the previous sta_newstate() function, with no effect on execution.

With this trick, we don’t have to worry about these first 6 bytes, as they are effectively discarded.

2. The second constraint of the primitive is that we are forced to overwrite exactly 182 bytes, so we cannot overwrite the first few bytes only. This is not really a problem. We can just fill the rest of the bytes with the same instruction bytes that are there in memory already.

3. The third constraint of the primitive is that the last 12 bytes that we write are the ies->data and ies->len fields, and these don’t disassemble to valid instructions. That’s a problem because these bytes are within sta_input(). If the kernel tries to execute these bytes, it won’t be long before it crashes. To work around this, we must have corrective code in our implant. When called for the first time, our implant must correct the last 12 bytes of garbage that we wrote into sta_input(). Although slightly annoying, this is not complicated to implement.

With all that established, we’re all set. Our implant will now execute each time sta_input() is called, meaning, each time a Wi-Fi frame is received by the target!

Frame 4: Corrective frame

Finally, to maintain the stability of the target, we send a final beacon frame where we overflow ies->data to be NULL and ies->len to be 0.

This ensures that the target won’t crash.

Subsequent communication channel

With the aforementioned four frames, we have a recipe to reliably inject an implant into the target’s kernel. The implant gets called in the same context as sta_input():

Notably, the second argument, m, is the memory region containing the buffer of the frame that the kernel is currently processing. The implant can therefore inspect that buffer (via %rsi) and act depending on its contents.

In other words, we have a communication channel with the implant. We can therefore code our implant as a server backdoor and send commands to it via this channel.

Full steps

Let’s recap:

1. A heap buffer overflow vulnerability exists in the FreeBSD kernel. An attacker can trigger this bug by sending a beacon frame with an oversized MeshId option.
2. Using that vulnerability, we can implement a write-what-where primitive that allows us to perform one kernel memory overwrite per beacon frame we send.
3. We can use that primitive three times to inject an implant into the target’s kernel.
4. A fourth beacon frame is used to clean up ies->data and ies->len, to prevent a crash.
5. Finally, our implant runs in the kernel of the target and acts as a full backdoor that can process subsequent Wi-Fi frames we send to it.

The Exploit

A full exploit can be found here. It injects a simple implant that calls printf() with the strings that the attacker subsequently sends. To use this exploit from a Linux machine that has a Wi-Fi card called wifi0, switch the card to monitor mode with:

Then, build and run the exploit for the desired target. For example, if you wish to target a pfSense 2.5.2 system:

Please exercise caution - this will exploit all vulnerable systems in your vicinity.

Once you have done this, look at the target’s tty0 console. You should see: “Hello there, I’m in the kernel”.

Thanks again to m00nbsd for providing this thorough write-up. They have contributed multiple bugs to the ZDI program over the last few years, and we certainly hope to see more submissions from them in the future. Until then, follow the team for the latest in exploit techniques and security patches.