Created hostapd tracking bugs for this issue:

Affects: epel-all [bug 1846008]
Affects: fedora-all [bug 1846007]

General Flaw summary:
Devices host UPnP servers in order to supply information to UPnP clients and allow them to send commands to the UPnP server. For example, a device (such as a printer, camera, or video game console) running a UPnP client can send an HTTP request of method M-SEARCH over UDP to the broadcast IP. This will cause UPnP servers on the network to reply with device information such as make, model, services offered, and URLs where commands can be sent to the server for further actions. UPnP also allows the client application to send an HTTP request of method SUBSCRIBE. This request allows the client to subscribe to events. In the SUBSCRIBE request, the client supplies a CALLBACK URL, which is where the server needs to send event notifications, in the form of NOTIFY requests back to the client. In fact, the specification allows for an unlimited number of URLs to be supplied as the CALLBACK URL. If a reply is not received from the first URL, the server moves to the second, third, and so on... Knowing this, the CallStranger flaw leverages:

1. When subscribing to UPnP-enabled device server events, a callback URL is supplied by the client to the server.
2. This URL is not limited in length by the UPnP specification
3. Unlimited number of URLs can be supplied in succession.
4. If TCP ports are closed at the current URL, the server will send n number of TCP SYN packets to keep trying for a while*
5. After multiple failures to connect, the server will again try this at the next URL. This allows for attempts on arbitrary many URLs/HTTPservers**
6. There is also no limitation on the data supplied in the callback URL. E.G. 127.0.0.1:port/unlimiteddatahere . This can be used to put excessive load on bandwidth and the server, as well as slam another service with lots of data.
7. The final feature is that the UPnP specification allowed these callback URL requests to be sent to hosts outside of the network, meaning that a UPnP client that is inside a local network could force a UPnP server in that network to send data outside of the network, which could be used to exfiltrate data and/or perform a DDoS attack in, e.g. a botnet. This could be accomplished if a client specified the callback URL as some resource on the Internet, for example.

* This also allows for SYN flooding. The exact number of SYN packets sent depends on OS and specific machine configurations.

** This can be leveraged to perform a port scan because an attacker knows that a port is open if no request is made to a subsequent URL in the CALLBACK url list.

Thus, the flaw could allow for DoS/DDoS attacks, data exfiltration, and port scanning. It should also be noted that there are numerous UPnP servers which listen on the Internet, instead of just on local networks, allowing for SUBSCRIBE and NOTIFY requests to be negotiated from/to outside the network.

Although the UPnP specification allowed the vectors mentioned above, there are other mitigations that can be put in place to prevent exploitation of this flaw, that we will list under the Mitigations heading. On April 17, 2020, the UPnP specification was updated[1] with:

"The subscription request containing a delivery URL not on the same network segment as the fully qualified event subscription URL shall not be accepted."

1. http://openconnectivity.org/developer/specifications/upnp-resources/upnp/#architectural

The wpa_supplicant build configuration does not build with CONFIG_WPS_UPNP=y or CONFIG_WPS_ER=y in RHEL 5, 6, 7, or 8. Thus the UPnP functionality is not enabled as shipped.

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-12695

Mitigation:

To mitigate this flaw, close off the UPnP UDP port (usually 1900) and UPnP service ports from the Internet using a firewall. It's important to note that UPnP service ports vary based on the device, so device documentation should be consulted. Do not expose UPnP servers to the Internet. Exploitation of this flaw relies on HTTP SUBSCRIBE and NOTIFY requests, which can be blocked using a network security appliance, as another mitigation option.

Statement:

This flaw does not affect the wpa_supplicant package as shipped with Red Hat Enterprise Linux 5, 6, 7, and 8. wpa_supplicant's WiFi Protected Setup (WPS) External Registrar functionality, which uses UPnP to act as a registrar for a WiFi access point, and hostapd's WPS UPnP functionality, are disabled in the build configuration. Additionally, wpa_supplicant's P2P functionality does not support UPnP as shipped in Red Hat Enterprise Linux 5, 6, 7 and 8.

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-12695

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:1789 https://access.redhat.com/errata/RHSA-2021:1789