This environment is built based on the “Huo Tian Network Attack and Defense Training Target Field”. The Huo Tian series products provide a simulator-level network environment construction system, which can flexibly design and configure the target network, and quickly build and reproduce scenarios. The products also connect to Internet of Vehicles devices, providing basic resource support for constructing a security training environment for the Internet of Vehicles.

Background

Recently, several domestic security laboratories have detected vulnerabilities targeting the open-source project BusyBox used in intelligent connected vehicles. This vulnerability was reported abroad in May 2022, and the currently released CVE information is as follows. The information indicates that in BusyBox version 1.35-x, the awk application has a denial-of-service vulnerability or may obtain code execution rights due to use after free.

Vulnerability Principle

According to the CVE release information announcement, this vulnerability belongs to a heap overflow vulnerability, specifically a use after free type. In simple terms, the formation process of a use after free vulnerability is as follows: if we allocate a block of memory and then free it, at this time, if we reallocate a block of the same size, the operating system will conveniently reassign the previously freed memory to us for memory space management. At this time, the previous allocation pointer has not been cleared, and if we reassign a value to the memory, it will affect the contents of the second memory allocation. The essence of use after free is that two pointers point to the same block of memory, and when one chunk is freed, the data in that chunk has partial control over the structure, modifying the control structure data with another pointer will change the program’s control flow.

For example, in the source code below, we use the pointer chunk1 to point to the 0x10 bytes of memory allocated by malloc, then copy the string “test1” into the memory. At this time, the printed chunk1 address is 0x8c71e260, and the content is test1. Then we free chunk1, and now use the chunk2 pointer to point to the newly allocated 0x10 bytes of memory, and the printed chunk2 address is also 0x8c71e260. If we write the string “test3” into the memory pointed to by the chunk1 pointer and print the content of chunk2, we will find that even though we did not modify the content of chunk2, the content of chunk2 has changed.

Knowing the general type of the vulnerability, we can conduct a simple analysis. First, download versions 1.35.0 and the latest 1.36.0 from the BusyBox official website (https://busybox.net/downloads/). According to the CVE release information, we know that the vulnerability exists in the awk application, so we directly use vimdiff to compare the awk.c files of the two versions. In the comparison with vimdiff, we found that there was a patch change in the case XC(OC_MOVE) of the evaluate function.

Open the corresponding code block in the unpatched 1.35.0 version awk.c file. This code block is located in the evaluate function, and in this case branch, the vulnerable function copyvar mentioned in the CVE announcement appears. Since we are still not very clear about the overall architecture and execution flow of the program, we first follow up on the specific situation that may have vulnerabilities, as heap overflow vulnerabilities generally occur near *alloc or free functions. Use after free vulnerabilities are mostly found in free functions, so we will focus on the free function in the next process.

Upon entering, we find that clrvar operates on the first parameter, and then the handle_special function processes dest. Upon entering, we find that the clrvar function calls the free function to release the memory.

The above two functions both use the var structure, which is defined as follows:

Next, return to the awk_main function to simply observe the execution flow. The program first performs a series of settings, specifying standard input and output, and then uses awk_getline to get user input, looping through the evaluate function for processing.

In the evaluate function, nvalloc first allocates heap memory for 2 var sizes. Then the pointer is named TMPVAR0. Based on the passed op structure information, it loops through for processing. In the loop processing, it uses a switch case branch, calling the copyvar function in XC(OC_MOVE).

Based on the previous process analysis and the patched code, if we can control the pointer L.v to point to tmpvars (TMPVAR0), then at this time, the user-modified pointer and the system-automatically allocated tmpvars point to the same block of memory. In the case XC(OC_MOVE), if one of the pointers pointing to the chunk is freed while the other pointer continues to use the chunk’s memory, modifying the freed chunk’s memory data will corrupt the free chunk list, leading to a heap overflow vulnerability.

Vulnerability Analysis

Due to the multi-platform nature of BusyBox, for the sake of convenience, I chose to operate on the Linux operating machine in the target field. The dynamic debugging process is as follows, after gdb debugging, breakpoints and attach processes are set.

Directly press c to run; the program asks us to input a string, which we can input arbitrarily.

The program directly breaks at the call free point, observing that RDI is empty, which we do not need to care about. Checking the stack trace shows that the program is called by the awk_getline function, which is where the user input is obtained in the previous analysis.

The heap space block layout information is as follows. We can see that the input “foo” string, the heap memory structure has not yet been damaged, and we continue to debug.

During debugging, the information of the released heap blocks is relatively complex, and we use the bins command to view the current free chunk list.

It ran to the evaluate function, where the heap memory for tmpvars is allocated using the nvalloc (xzalloc) function in the source code.

It directly breaks in the copyvar function inside case XC(OC_MOVE). The first parameter of copyvar is L.v, and the second parameter is R.v. Here, L.v has been modified to point to tmpvars, so both pointers point to the memory of tmpvars. The subsequent call will involve the free function for release.

Entering the copyvar function, running to call clrvar, where rdi is the address of the first parameter L.v. clrvar will call the free function for release.

After the run enters the handle_special function, the subsequent process is relatively complex. We directly set a breakpoint at the vulnerability trigger point getvar_i. After running, the breakpoint stops at the call getvar_i function, and we analyze it.

In the getvar_i function, the pointer pointing to 0x55555585caa0 chunk is modified (v->type).

At this point, the v->type processed in the getvar_i function is the control structure of the tmpvars free chunk, and the function directly processes it, causing changes to the heap structure.

At this point, the data 0x55555585caf0 in 0x55555585caa0 has been modified. The original free chunk list has been damaged, and the modified 0x55555585caa0 points to the next free chunk, which has been modified to 0x55555585c9f0.

When we perform the second string input, we will continue to apply for and release heap space. When applying for the chunk at address 0x55555585c9f0, data changes will occur in the heap space, causing the program to crash.

The address 0x55555585c9f0 has already been applied for, and at this time, the chunk structure has been damaged, and the gdb plugin can no longer recognize the remaining content space of the heap structure.

The heap block identifier has been cleared, so the corresponding heap block’s starting position cannot be found.

As we continue debugging, the program crashes.

The following image shows another situation that occurred during a poc test, where the topchunk identifier was modified to 0. When the heap continues to apply and release, the program will also crash.

Vulnerability Reproduction

After downloading BusyBox, directly compile and install using the source code.

make menuconfig
make
make install

Using the published poc for testing, it was found that the vulnerability was triggered.

Due to the different compilation and use of BusyBox in different systems, and the different protections enabled after compilation in different systems, the method of obtaining execution permissions is also different.

Summary

Overall analysis shows that this vulnerability is not very exploitable, and the method of obtaining execution permissions is relatively complex. However, due to the possibility of obtaining execution permissions, users using vulnerable versions of BusyBox should upgrade to the latest version as soon as possible.