Submit #811380: D-Link DIR816 DIR-816A2_FWv1.10CNB05_R1B011D88210.img Command Injection

The portForward form handler accepts the user-controlled ip_address parameter together with a port range, protocol and enable flag. The handler validates the port fields numerically and checks the comment field for ; and ,, but the ip_address field is only checked by sub_445E7C(). This is an unsafe validation boundary for command construction because the original request string is not normalized, shell-escaped, or filtered for command metacharacters before being stored.

After validation, sub_44EFF0() serializes the rule as ip_address,fromPort,toPort,protocol,enable and writes it to nvram as PortForwardRules through nvram_bufset()/nvram_set(). The tainted value becomes persistent configuration data. During firewall initialization or rule refresh, sub_456010() reads PortForwardRules, extracts the first comma-separated field into v12, and again only calls the weak IP checker. It then passes v12 into sub_4473C4().

sub_4473C4() constructs an iptables NAT command and places the extracted ip_address directly into the command string with --to %s. The completed buffer v10 is executed by doSystem(v10). Therefore, a crafted ip_address supplied through goform/portForward can flow from the web request into nvram and later into a shell command execution sink, resulting in stored command injection when the firewall rules are applied.

Vulnerability chain: websGetVar("ip_address") -> sub_445E7C() weak validation -> nvram_bufset("PortForwardRules") -> nvram_bufget("PortForwardRules") -> getNthValueSafe(..., v12) -> sub_4473C4(..., v12, ...) -> doSystem(v10).

• Quelle: ⚠️ https://github.com/lipenghai/iot_bug/blob/main/D-Link/DIR816/3.md
• Benutzer: stksgg (UID 97520)
• Einreichung: 23.04.2026 14:11 (vor 1 Monat)
• Moderieren: 11.05.2026 18:24 (18 days later)
• Status: Akzeptiert
• VulDB Eintrag: 362662 [D-Link DIR-816 1.10CNB05_R1B011D88210 portForward ip_address erweiterte Rechte]
• Punkte: 20