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.