Bug 1846006 (CVE-2020-12695) - CVE-2020-12695 hostapd: UPnP SUBSCRIBE misbehavior in WPS AP
Summary: CVE-2020-12695 hostapd: UPnP SUBSCRIBE misbehavior in WPS AP
Status: NEW
Alias: CVE-2020-12695
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1846008 1846588 1846589 1846007
Blocks: 1846010
TreeView+ depends on / blocked
Reported: 2020-06-10 14:54 UTC by Guilherme de Almeida Suckevicz
Modified: 2020-06-23 23:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-06-11 23:20:25 UTC

Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2020-06-10 14:54:17 UTC
The Open Connectivity Foundation UPnP specification before 2020-04-17 does not forbid the acceptance of a subscription request with a delivery URL on a different network segment than the fully qualified event-subscription URL, aka the CallStranger issue.


Comment 1 Guilherme de Almeida Suckevicz 2020-06-10 14:54:38 UTC
Created hostapd tracking bugs for this issue:

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

Comment 2 Todd Cullum 2020-06-11 18:17:08 UTC
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. . 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

Comment 4 Todd Cullum 2020-06-11 21:58:12 UTC
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.

Comment 5 Product Security DevOps Team 2020-06-11 23:20:25 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 7 Todd Cullum 2020-06-12 01:34:13 UTC

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.

Comment 11 Todd Cullum 2020-06-19 17:23:48 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.