Description
This code is vulnerable to CWE-122 (Heap-based Buffer Overflow) as it uses unsafe string concatenation functions alongside fixed-size heap memory allocation. The do_request function processes user-provided username and password inputs extracted from HTTP POST requests. When handling user registration, the function allocates a fixed 200-byte heap buffer via malloc(), then uses strcpy() and strcat() to concatenate SQL template strings, wrapping characters, and unvalidated username/password inputs into this buffer.
Impacted code
|
char *sql_insert = (char *)malloc(sizeof(char) * 200); |
|
strcpy(sql_insert, "INSERT INTO user(username, passwd) VALUES("); |
|
strcat(sql_insert, "'"); |
|
strcat(sql_insert, name); |
|
strcat(sql_insert, "', '"); |
|
strcat(sql_insert, password); |
|
strcat(sql_insert, "')"); |
The issue is that no bounds checking is performed to verify if the total length of the concatenated SQL string (SQL template + wrapping characters + username + password) exceeds the 200-byte buffer size. Since usernames and passwords can each contain up to 99 bytes of user input (for a combined maximum of 198 bytes), the total length of the concatenated string easily exceeds the buffer’s capacity. This triggers a heap-based buffer overflow that corrupts metadata in adjacent heap memory, causing server crashes, and potentially enabling arbitrary code execution under specific conditions.
Exploit
An attacker can exploit this heap overflow vulnerability by sending a maliciously crafted HTTP POST request with overly long username and password values. For example:
POST /3CGISQL.cgi HTTP/1.1
Host: target-server
Content-Type: application/x-www-form-urlencoded
Content-Length: 175
user=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB&password=CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
In this case, when the code parses the username and password parameters from the request body and concatenates them with the 43-byte SQL template string, 6 bytes of wrapping characters, and 1-byte NULL terminator into the 200-byte heap buffer via strcpy() and strcat(), it triggers a heap-based buffer overflow (the total length of the concatenated string reaches 210 bytes, exceeding the 200-byte buffer capacity). This overflow corrupts the metadata of adjacent heap blocks and immediately causes the TinyWebServer process to crash.
The attacker could use a similar approach with any combination of username and password lengths where their total exceeds 150 bytes (e.g., 75 bytes for username + 76 bytes for password, 99 bytes for username + 99 bytes for password). They only need to construct an HTTP POST request that matches the expected application/x-www-form-urlencoded content format and contains sufficiently long input values to exceed the buffer's capacity.
Impacted
All commits and branches of the TinyWebServer codebase (no official releases published) are affected because the vulnerability stems from the fundamental use of fixed-size heap memory allocation combined with unsafe string concatenation functions (strcpy()/strcat()), which is embedded in the user registration processing logic of the do_request function. No code changes or mitigations have been implemented in any commit to address the heap-based buffer overflow risk caused by the lack of bounds checking on user input length.
Description
This code is vulnerable to CWE-122 (Heap-based Buffer Overflow) as it uses unsafe string concatenation functions alongside fixed-size heap memory allocation. The
do_requestfunction processes user-provided username and password inputs extracted from HTTP POST requests. When handling user registration, the function allocates a fixed 200-byte heap buffer viamalloc(), then usesstrcpy()andstrcat()to concatenate SQL template strings, wrapping characters, and unvalidated username/password inputs into this buffer.Impacted code
TinyWebServer/http/http_conn.cpp
Lines 425 to 431 in 4bcf887
The issue is that no bounds checking is performed to verify if the total length of the concatenated SQL string (
SQL template+wrapping characters+username+password) exceeds the 200-byte buffer size. Since usernames and passwords can each contain up to 99 bytes of user input (for a combined maximum of 198 bytes), the total length of the concatenated string easily exceeds the buffer’s capacity. This triggers a heap-based buffer overflow that corrupts metadata in adjacent heap memory, causing server crashes, and potentially enabling arbitrary code execution under specific conditions.Exploit
An attacker can exploit this heap overflow vulnerability by sending a maliciously crafted HTTP POST request with overly long username and password values. For example:
In this case, when the code parses the username and password parameters from the request body and concatenates them with the 43-byte SQL template string, 6 bytes of wrapping characters, and 1-byte NULL terminator into the 200-byte heap buffer via
strcpy()andstrcat(), it triggers a heap-based buffer overflow (the total length of the concatenated string reaches 210 bytes, exceeding the 200-byte buffer capacity). This overflow corrupts the metadata of adjacent heap blocks and immediately causes the TinyWebServer process to crash.The attacker could use a similar approach with any combination of username and password lengths where their total exceeds 150 bytes (e.g., 75 bytes for username + 76 bytes for password, 99 bytes for username + 99 bytes for password). They only need to construct an HTTP POST request that matches the expected application/x-www-form-urlencoded content format and contains sufficiently long input values to exceed the buffer's capacity.
Impacted
All commits and branches of the TinyWebServer codebase (no official releases published) are affected because the vulnerability stems from the fundamental use of fixed-size heap memory allocation combined with unsafe string concatenation functions (
strcpy()/strcat()), which is embedded in the user registration processing logic of the do_request function. No code changes or mitigations have been implemented in any commit to address the heap-based buffer overflow risk caused by the lack of bounds checking on user input length.