Describe the set-up
Board: STM32F769I-Discovery
Software: STM32CubeF7, revision c2ecfd2
Affected example: Projects/STM32F769I-Discovery/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS
Affected file: Src/httpserver-netconn.c
Affected function: http_server_serve()
IDE/compiler: The issue is in the C source and is not compiler-specific.
Describe the bug
The Netconn HTTP server checks only that the received network buffer contains at least five bytes before comparing the buffer against substantially longer HTTP request prefixes.
Specifically, after:
if ((buflen >= 5) && (strncmp(buf, "GET /", 5) == 0))
the code performs comparisons such as:
strncmp(buf, "GET /STM32F7xx_files/ST.gif", 27)
strncmp(buf, "GET /STM32F7xx_files/stm32.jpg", 30)
strncmp(buf, "GET /STM32F7xx_files/logo.jpg", 29)
as well as additional 24-, 19-, and 6-byte comparisons, without first verifying that buflen is large enough for those operations.
Because data returned by netbuf_data() is length-delimited and is not guaranteed to contain bytes beyond buflen, a sufficiently short request whose contents match the beginning of one of these prefixes can cause strncmp() to read beyond the received payload.
This results in an out-of-bounds read. Depending on the memory layout and network-buffer allocation, the read may cause a fault or may consume adjacent memory. The practical security impact therefore depends on the deployed configuration.
How To Reproduce
Run the LwIP_HTTP_Server_Netconn_RTOS example and connect to the HTTP server on TCP port 80.
The suspected module is the LwIP Netconn HTTP server example, specifically http_server_serve() in httpserver-netconn.c.
Send a short TCP payload consisting of exactly:
GET /
with a payload length of five bytes.
netbuf_data() returns the buffer with buflen == 5. The following condition succeeds:
if ((buflen >= 5) && (strncmp(buf, "GET /", 5) == 0))
Execution then reaches:
strncmp((char const *)buf, "GET /STM32F7xx_files/ST.gif", 27)
The first five characters match, so strncmp() attempts to inspect the next byte even though the received payload contains only five bytes. This causes a read beyond the valid netbuf payload.
The same underlying issue applies to the other fixed-length request-prefix comparisons when the received request is shorter than the corresponding comparison length.
Additional context
Each prefix comparison should verify that the received buffer is at least as long as the number of bytes being compared. For example:
if ((buflen >= 27) &&
(strncmp((char const *)buf,
"GET /STM32F7xx_files/ST.gif", 27) == 0))
{
...
}
Equivalent bounds checks should be added for the 30-, 29-, 24-, 19-, and 6-byte comparisons.
Alternatively, the request parsing logic could be changed so that all comparisons operate explicitly within the length returned by netbuf_data().
The code should not rely on the network buffer being NUL-terminated or on unused allocator space being readable beyond buflen.
Describe the set-up
Board: STM32F769I-Discovery
Software: STM32CubeF7, revision c2ecfd2
Affected example: Projects/STM32F769I-Discovery/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS
Affected file: Src/httpserver-netconn.c
Affected function: http_server_serve()
IDE/compiler: The issue is in the C source and is not compiler-specific.
Describe the bug
The Netconn HTTP server checks only that the received network buffer contains at least five bytes before comparing the buffer against substantially longer HTTP request prefixes.
Specifically, after:
if ((buflen >= 5) && (strncmp(buf, "GET /", 5) == 0))
the code performs comparisons such as:
strncmp(buf, "GET /STM32F7xx_files/ST.gif", 27)
strncmp(buf, "GET /STM32F7xx_files/stm32.jpg", 30)
strncmp(buf, "GET /STM32F7xx_files/logo.jpg", 29)
as well as additional 24-, 19-, and 6-byte comparisons, without first verifying that buflen is large enough for those operations.
Because data returned by netbuf_data() is length-delimited and is not guaranteed to contain bytes beyond buflen, a sufficiently short request whose contents match the beginning of one of these prefixes can cause strncmp() to read beyond the received payload.
This results in an out-of-bounds read. Depending on the memory layout and network-buffer allocation, the read may cause a fault or may consume adjacent memory. The practical security impact therefore depends on the deployed configuration.
How To Reproduce
Run the LwIP_HTTP_Server_Netconn_RTOS example and connect to the HTTP server on TCP port 80.
The suspected module is the LwIP Netconn HTTP server example, specifically http_server_serve() in httpserver-netconn.c.
Send a short TCP payload consisting of exactly:
GET /
with a payload length of five bytes.
netbuf_data() returns the buffer with buflen == 5. The following condition succeeds:
if ((buflen >= 5) && (strncmp(buf, "GET /", 5) == 0))
Execution then reaches:
strncmp((char const *)buf, "GET /STM32F7xx_files/ST.gif", 27)
The first five characters match, so strncmp() attempts to inspect the next byte even though the received payload contains only five bytes. This causes a read beyond the valid netbuf payload.
The same underlying issue applies to the other fixed-length request-prefix comparisons when the received request is shorter than the corresponding comparison length.
Additional context
Each prefix comparison should verify that the received buffer is at least as long as the number of bytes being compared. For example:
if ((buflen >= 27) &&
(strncmp((char const *)buf,
"GET /STM32F7xx_files/ST.gif", 27) == 0))
{
...
}
Equivalent bounds checks should be added for the 30-, 29-, 24-, 19-, and 6-byte comparisons.
Alternatively, the request parsing logic could be changed so that all comparisons operate explicitly within the length returned by netbuf_data().
The code should not rely on the network buffer being NUL-terminated or on unused allocator space being readable beyond buflen.