Re: UPnP SUBSCRIBE misbehavior in hostapd WPS AP

Cy Schubert <[email protected]> Mon, 08 Jun 2020 17:23:56 -0700
Newsgroups gmane.linux.drivers.hostap
Message-ID <[email protected]>
In message <[email protected]>, Jouni Malinen writes:
> Published: June 8, 2020
> Identifiers:
> - VU#339275 and CVE-2020-12695 (applying for the callback URL in other
>   network case, but not the other items discussed in this advisory)
> Latest version available from: https://w1.fi/security/2020-1/
>
> Vulnerability
>
> General security vulnerability in the way the callback URLs in the UPnP
> SUBSCRIBE command are used were reported (VU#339275, CVE-2020-12695).
> Some of the described issues may be applicable to the use of UPnP in WPS
> AP mode functionality for supporting external registrars.
>
> Such issues could allow a device connected to the local network (i.e., a
> device that has been authorized to transmit packets in the network in
> which the AP is located) could trigger the AP to initiate a HTTP
> (TCP/IP) connection to an arbitrary URL, including connections to
> servers in external networks. This could have a security implication if
> traffic from the local network to external destinations have different
> rules (e.g., firewall and packet inspection) for different local hosts
> and the AP having access to external hosts while the attacker controlled
> local device not having such access. Such deployment cases may not be
> common for networks where WPS would be enabled, but it is not possible
> to completely rule out the applicability to cases where hostapd is used
> to control a WPS enabled AP.
>
> In addition to the more generic issues with the UPnP protocol, couple of
> implementation specific issues in hostapd were discovered while
> reviewing this area of the WPS implementation. These issues could allow
> local devices (i.e., devices that have been authorized to transmit
> packets in the network in which the AP is located) to trigger
> misbehavior in hostapd and cause the process to either get terminated or
> to start using more CPU resources by using a specially constructed
> SUBSCRIBE command.
>
> All these issues require the attacker to be able to discover the UPnP
> service provided by hostapd and to open a TCP connection toward the IP
> address of the AP. The former requires access to the local network to be
> able to receive broadcast packets and the latter requires access to
> initiate TCP/IP connection to the IP address used by the AP. In most
> common AP deployment cases, both of these operations are available only
> from the local network.
>
>
> Vulnerable versions/configurations
>
> All hostapd versions with WPS AP support with UPnP enabled in the build
> parameters (CONFIG_WPS_UPNP=y) and in the runtime configuration
> (upnp_iface).
>
>
> Possible mitigation steps
>
> - Disable WPS UPnP support in the hostapd runtime configuration by
>   removing the upnp_iface parameter.
>
> - Merge the following commits to hostapd and rebuild:
>
>   For CVE-2020-12695:
>   WPS UPnP: Do not allow event subscriptions with URLs to other networks
>   For the other issues:
>   WPS UPnP: Fix event message generation using a long URL path
>   WPS UPnP: Handle HTTP initiation failures for events more properly
>
>   These patches are available from https://w1.fi/security/2020-1/
>
> - Update to hostapd v2.10 or newer, once available
>
> -- 
> Jouni Malinen                                            PGP id EFC895FA
>
> _______________________________________________
> Hostap mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/hostap
>

This won't build under FreeBSD. This patch works around the issue.

diff --git a/src/wps/wps_upnp.c b/src/wps/wps_upnp.c
index ab685d52e..4aa34a723 100644
--- a/src/wps/wps_upnp.c
+++ b/src/wps/wps_upnp.c
@@ -951,7 +951,11 @@ int get_netif_info(const char *net_if, unsigned 
*ip_addr, char **ip_addr_text,
 				   errno, strerror(errno));
 			goto fail;
 		}
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+		addr = (struct sockaddr_in *) &req.ifr_addr;
+#else
 		addr = (struct sockaddr_in *) &req.ifr_netmask;
+#endif
 		netmask->s_addr = addr->sin_addr.s_addr;
 	}
 

-- 
Cheers,
Cy Schubert <[email protected]>
FreeBSD UNIX:  <[email protected]>   Web:  https://FreeBSD.org
NTP:           <[email protected]>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.