Multiple stack-based buffer overflow vulnerabilities exist in the formPingCmd functionality of Planet WGR-500 v1.3411b190912. A specially crafted series of HTTP requests can lead to stack-based buffer overflow. An attacker can send a series of HTTP requests to trigger these vulnerabilities.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Planet WGR-500 v1.3411b190912
WGR-500 - https://www.planet.com.tw/
8.8 - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE-121 - Stack-based Buffer Overflow
The WGR-500 is a high-performance industrial router designed to support VLAN configurations, equipped with a built-in firewall, and offering a robust suite of advanced networking functionalities.
The WGR-500 includes a feature to test network connectivity with other computers using the ping utility. This functionality is implemented within the web server’s formPingCmd function:
void formPingCmd(undefined4 param_1)
{
char *submit_url;
char* ipaddr;
char* counts;
[...]
char buffer_32 [32];
char ping_command [100];
char buffer_260 [260];
[1] submit_url = get_from_params(param_1,"submit-url","");
[2] ipaddr = get_from_params(param_1,"ipaddr","");
[3] counts = get_from_params(param_1,"counts","");
[4] sprintf(ping_command,"ping -c %s %s 2>&1 > %s &",counts,ipaddr,"/tmp/pingResult");
[5] sprintf(buffer_260,submit_url);
[6] sprintf(buffer_32,"ipaddr=%s",ipaddr);
[7] strcat(buffer_260,buffer_32);
[...]
return;
}
This function uses three provided arguments: ipaddr, counts, and submit_url, which are combined to prepare various strings:
- At [4], it constructs the ping command string: "ping -c <counts> <ipaddr> 2>&1 > %s &"
- At [5], it populates buffer_260 with the submit_url string.
- At [6], it populates buffer_32 with the string: "ipaddr=<ipaddr>".
- At [7], it concatenates the buffer_32 string (populated at [6]) to the buffer_260 string (populated at [5]).
The formPingCmd API contains several stack buffer overflow vulnerabilities, which are exploitable via the request parameters. An attacker could leverage these vulnerabilities to achieve arbitrary code execution. The following sections detail each way that can lead to a stack buffer overflow.
At [2], the ipaddr request parameter is fetched. This parameter is then used at [4] to construct the string "ping -c <counts> <ipaddr> 2>&1 > %s &". This string is written into the ping_command stack buffer, which has a size of 100 bytes. However, there is no size check performed before the sprintf operation. An attacker can exploit this lack of a size check to cause a buffer overflow in the ping_command buffer, potentially leading to arbitrary code execution.
At [3], the counts request parameter is fetched. This parameter is subsequently used at [4] to compose the string "ping -c <counts> <ipaddr> 2>&1 > %s &". This resulting string is written into the ping_command stack buffer, which is 100 bytes in size. However, no size check is performed before the sprintf operation. An attacker can exploit this absence of a size check to trigger a buffer overflow on the ping_command buffer, potentially leading to arbitrary code execution.
At [1], the submit-url request parameter is fetched. This parameter is then copied at [5] into the buffer_260 buffer, which has a size of 260 bytes. However, there is no size check performed before the sprintf operation. An attacker can exploit this lack of a size check to cause a buffer overflow in the buffer_260 buffer, potentially leading to arbitrary code execution.
At [1] and [2], the submit-url and ipaddr request parameters are fetched, respectively. Subsequently, at [5], the submit-url parameter is copied into buffer_260, a buffer 260 bytes in length. At [6], the string "ipaddr=<ipaddr>" is composed using the ipaddr parameter, and the resulting string is written into the buffer_32 buffer. Finally, at [7], buffer_32 is concatenated to buffer_260. However, no size check is performed before this strcat operation. An attacker can exploit this lack of a size check to cause a buffer overflow in the buffer_260 buffer, potentially leading to arbitrary code execution.
2025-07-30 - Initial Vendor Contact
2025-08-01 - Vendor Disclosure
2025-08-01 - Vendor Confirmed Receipt
2025-09-01 - Status Update Request
2025-09-01 - Vendor Reply
2025-09-24 - Vendor Reply Acknowledged. Release Date Announced.
2025-10-07 - Public Release
Discovered by Francesco Benvenuto of Cisco Talos.