CVE-2024-45064
A buffer overflow vulnerability exists in the FileX Internal RAM interface functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted set of network packets can lead to code execution. An attacker can send a sequence of requests to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
STMicroelectronics X-CUBE-AZRT-H7RS 1.0.0
STMicroelectronics X-CUBE-AZRTOS-F7 1.1.0
STMicroelectronics X-CUBE-AZRTOS-F4 1.1.0
STMicroelectronics X-CUBE-AZRTOS-G0 1.1.0
STMicroelectronics X-CUBE-AZRTOS-G4 2.0.0
STMicroelectronics X-CUBE-AZRTOS-L4 2.0.0
STMicroelectronics X-CUBE-AZRTOS-L5 2.0.0
STMicroelectronics X-CUBE-AZRTOS-WB 2.0.0
STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0
STMicroelectronics X-CUBE-AZRTOS-H7 3.3.0
X-CUBE-AZRTOS-WL - https://www.st.com/en/embedded-software/x-cube-azrtos-wl.html X-CUBE-AZRT-H7RS - https://www.st.com/en/embedded-software/x-cube-azrt-h7rs.html X-CUBE-AZRTOS-F4 - https://www.st.com/en/embedded-software/x-cube-azrtos-f4.html X-CUBE-AZRTOS-F7 - https://www.st.com/en/embedded-software/x-cube-azrtos-f7.html X-CUBE-AZRTOS-G0 - https://www.st.com/en/embedded-software/x-cube-azrtos-g0.html X-CUBE-AZRTOS-G4 - https://www.st.com/en/embedded-software/x-cube-azrtos-g4.html X-CUBE-AZRTOS-H7 - https://www.st.com/en/embedded-software/x-cube-azrtos-h7.html X-CUBE-AZRTOS-L4 - https://www.st.com/en/embedded-software/x-cube-azrtos-l4.html X-CUBE-AZRTOS-L5 - https://www.st.com/en/embedded-software/x-cube-azrtos-l5.html X-CUBE-AZRTOS-WB - https://www.st.com/en/embedded-software/x-cube-azrtos-wb.html
8.5 - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
X-CUBE-AZRTOS-F7 (Azure RTOS STM32Cube Expansion Package) offers comprehensive integration of Microsoft Azure RTOS within the STM32Cube environment for the STM32F7 series microcontrollers. This Expansion Package encompasses a range of Azure RTOS middleware components, including the RTOS (ThreadX), USB Host and Device (USBX), file system with support for NOR and NAND flash memories (FileX and LevelX), and networking capabilities that include Ethernet and WiFi media (NetX Duo).
The NetXDuo http server sample implementation is used to demonstrate this vulnerability. However, this vulnerability affects any application using the RAM disk driver with a vulnerable configuration. The initial values for configuring the RAM disk driver are copied from that sample code provided in the X-CUBE-AZRTOS-F7 repository https://github.com/STMicroelectronics/x-cube-azrtos-f7/blob/main/Middlewares/ST/netxduo/samples/demo_netxduo_https.c.
The RAM disk driver is initialized during application start up with a call to the function fx_media_format. Below is an example of this initialization:
status = fx_media_format(&ram_disk,
fx_stm32_sram_driver, // Driver entry
demo.ram_disk_memory, // RAM disk memory pointer /*[1] size 4096*/
DataBuffer, // Media buffer pointer
sizeof(DataBuffer), // Media buffer size
"MY_RAM_DISK", // Volume Name
1, // Number of FATs
32, // Directory Entries
0, // Hidden sectors
256, // Total sectors /*[2]*/
512, // Sector size /*[3]*/
8, // Sectors per cluster
1, // Heads
1); // Sectors per track
The Total sectors ([2]) multiplied by Sector size ([3]) equals 131,072 which is much larger than 4096 bytes allocated for the size of the RAM disk memory pointer at [1]. There are no checks performed to ensure that the RAM disk driver is configured properly, which leads to the vulnerability described below.
When receiving a PUT request, the NetXDuo http server implementation will create and write the specified file and it’s contents to the filesystem using the FileX API fx_file_write.
File: nx_web_http_server.c
4213: VOID _nx_web_http_server_put_process(NX_WEB_HTTP_SERVER *server_ptr, NX_PACKET *packet_ptr)
4214: {
...
4481: /* Write the content found in this packet. */
4482: status = fx_file_write(&(server_ptr -> nx_web_http_server_file), (packet_ptr -> nx_packet_prepend_ptr + offset),
4483: ((ULONG)(packet_ptr -> nx_packet_append_ptr - packet_ptr -> nx_packet_prepend_ptr) - offset));
After a series of intermediate functions, the RAM disk driver function fx_stm32_sram_driver is called with a WRITE request, which corresponds to the switch case below.
File: fx_stm32_sram_driver.c
81: case FX_DRIVER_WRITE:
82: {
83:
84: /* Calculate the RAM disk sector offset */
85: destination_buffer = (UCHAR *)FX_SRAM_DISK_BASE_ADDRESS + /*[4]*/
86: ((media_ptr->fx_media_driver_logical_sector + media_ptr->fx_media_hidden_sectors) * media_ptr->fx_media_bytes_per_sector);
87:
88: /* Copy the source to the RAM sector. */
89: _fx_utility_memory_copy(media_ptr->fx_media_driver_buffer, destination_buffer,
90: media_ptr->fx_media_driver_sectors * media_ptr->fx_media_bytes_per_sector); /*[5]*/
91:
92: /* Successful driver request. */
93: media_ptr -> fx_media_driver_status = FX_SUCCESS;
94: break;
95: }
At [4] a pointer to the memory location that should be written to is calculated. The pointer FX_SRAM_DISK_BASE_ADDRESS points to the buffer corresponding to the RAM disk which was provided when the application was initialized at [1]. The value for media_ptr -> fx_media_driver_logical_sector will be incremented until the value provided in the initialization [2]. The value for media_ptr -> fx_media_bytes_per_sector is the Sector size provided during initialization at [3]. The issue is that there is no validation performed to ensure that the calculation above at [4] will not result in the pointer destination_buffer pointing outside the bounds of the provided RAM disk buffer.
As you can see below, the function fx_utility_memory_copy at [5] is simply a wrapper for the libc memcpy function. The result is that user supplied data via an HTTP PUT request will overflow the RAM disk buffer. This buffer overflow could overwrite a function pointer in another object leading to code execution.
File: fx_utility_memory_copy.c
82: VOID _fx_utility_memory_copy(UCHAR *source_ptr, UCHAR *dest_ptr, ULONG size)
83: {
84:
85: /* Copy the memory. */
86: memcpy(dest_ptr, source_ptr, size); /* Use case of memcpy is verified. */
87: }
Program received signal SIGTRAP, Trace/breakpoint trap.
MemManage_Handler () at ../Core/Src/stm32f7xx_it.c:102
102 {
bt
#0 MemManage_Handler () at ../Core/Src/stm32f7xx_it.c:102
#1 <signal handler called>
#2 0x41414140 in ?? ()
#3 0x0802662e in webserver_request_notify_callback (server_ptr=0x20004330 <HTTPServer>, request_type=1, resource=0x2000433c <HTTPServer+12> "/test.txt", packet_ptr=0x20064558 <nx_byte_pool_buffer+9560>) at ../NetXDuo/App/app_netxduo.c:477
#4 0x08012158 in _nx_web_http_server_get_process (server_ptr=0x20004330 <HTTPServer>, request_type=1, packet_ptr=0x20064558 <nx_byte_pool_buffer+9560>) at ../Middlewares/ST/netxduo/addons/web/nx_web_http_server.c:3778
#5 0x08011a08 in _nx_web_http_server_receive_data (tcpserver_ptr=0x20004578 <HTTPServer+584>, session_ptr=0x200047e4 <HTTPServer+1204>) at ../Middlewares/ST/netxduo/addons/web/nx_web_http_server.c:3128
#6 0x080110b2 in _nx_tcpserver_data_process (server_ptr=0x20004578 <HTTPServer+584>) at ../Middlewares/ST/netxduo/addons/web/nx_tcpserver.c:1048
#7 0x08011284 in _nx_tcpserver_thread_entry (tcpserver_address=536888696) at ../Middlewares/ST/netxduo/addons/web/nx_tcpserver.c:1307
#8 0x08023ff4 in _tx_thread_shell_entry () at ../Middlewares/ST/threadx/common/src/tx_thread_shell_entry.c:114
#9 <signal handler called>
i r
r0 0x2d 45
r1 0x8028742 134383426
r2 0x74 116
r3 0x41414141 1094795585
r4 0x200781e4 537362916
r5 0x0 0
r6 0x0 0
r7 0x200781d8 537362904
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x80000000 -2147483648
sp 0x2007ffc8 0x2007ffc8
lr 0xfffffffd -3
pc 0x80011f0 0x80011f0 <MemManage_Handler>
xpsr 0x21000004 553648132
fpscr 0x0 0
msp 0x2007ffc8 0x2007ffc8
psp 0x20078198 0x20078198 <nx_byte_pool_buffer+90520>
primask 0x0 0
basepri 0x0 0
faultmask 0x0 0
control 0x0 0
Developers should ensure that the provided values for total sectors multiplied by sector size are less than the size of the buffer provided for the ram disk memory when initializing the ramdisk with the call to fx_media_format. In reference to the call above fx_media_format ensure that [2]*[3] < sizeof([1]).
2024-11-04 - Vendor Disclosure
2025-03-27 - Vendor Patch Release
2025-04-02 - Public Release
Discovered by Kelly Patterson of Cisco Talos.