UPnP SUBSCRIBE misbehavior in hostapd WPS AP

As published by our hostapd  upstream

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

Obtained from:	https://w1.fi/security/2020-1/
MFH:		2020Q2
Security:	VU#339275 and CVE-2020-12695

3 files changed, 28 insertions, 7 deletions

diff --git a/security/wpa_supplicant/Makefile b/security/wpa_supplicant/Makefile
index f96430416eea..84f566028f14 100644
--- a/security/wpa_supplicant/Makefile
+++ b/security/wpa_supplicant/Makefile
@@ -2,11 +2,14 @@
 
 PORTNAME=	wpa_supplicant
 PORTVERSION=	2.9
-PORTREVISION=	5
+PORTREVISION=	6
 CATEGORIES=	security net
 MASTER_SITES=	https://w1.fi/releases/
 
-PATCH_SITES=	https://w1.fi/security/2018-1/:2018_1
+PATCH_SITES=	https://w1.fi/security/2020-1/
+PATCHFILES=	0001-WPS-UPnP-Do-not-allow-event-subscriptions-with-URLs-.patch:-p1 \
+		0002-WPS-UPnP-Fix-event-message-generation-using-a-long-U.patch:-p1 \
+		0003-WPS-UPnP-Handle-HTTP-initiation-failures-for-events-.patch:-p1
 
 MAINTAINER=	cy@FreeBSD.org
 COMMENT=	Supplicant (client) for WPA/802.1x protocols
diff --git a/security/wpa_supplicant/distinfo b/security/wpa_supplicant/distinfo
index 1854b1f347aa..e55b99991e43 100644
--- a/security/wpa_supplicant/distinfo
+++ b/security/wpa_supplicant/distinfo
@@ -1,3 +1,9 @@
-TIMESTAMP = 1566442248
+TIMESTAMP = 1591652317
 SHA256 (wpa_supplicant-2.9.tar.gz) = fcbdee7b4a64bea8177973299c8c824419c413ec2e3a95db63dd6a5dc3541f17
 SIZE (wpa_supplicant-2.9.tar.gz) = 3231785
+SHA256 (0001-WPS-UPnP-Do-not-allow-event-subscriptions-with-URLs-.patch) = 2d9a5b9d616f1b4aa4a22b967cee866e2f69b798b0b46803a7928c8559842bd7
+SIZE (0001-WPS-UPnP-Do-not-allow-event-subscriptions-with-URLs-.patch) = 5909
+SHA256 (0002-WPS-UPnP-Fix-event-message-generation-using-a-long-U.patch) = 49feb35a5276279b465f6836d6fa2c6b34d94dc979e8b840d1918865c04260de
+SIZE (0002-WPS-UPnP-Fix-event-message-generation-using-a-long-U.patch) = 2284
+SHA256 (0003-WPS-UPnP-Handle-HTTP-initiation-failures-for-events-.patch) = a8212a2d89a5bab2824d22b6047e7740553df163114fcec94832bfa9c5c5d78a
+SIZE (0003-WPS-UPnP-Handle-HTTP-initiation-failures-for-events-.patch) = 1553
diff --git a/security/wpa_supplicant/files/patch-src_wps_wps__upnp.c b/security/wpa_supplicant/files/patch-src_wps_wps__upnp.c
index 00eab87b6ac2..1c7035e9a77d 100644
--- a/security/wpa_supplicant/files/patch-src_wps_wps__upnp.c
+++ b/security/wpa_supplicant/files/patch-src_wps_wps__upnp.c
@@ -1,6 +1,6 @@
---- src/wps/wps_upnp.c.orig	2015-03-15 17:30:39 UTC
-+++ src/wps/wps_upnp.c
-@@ -837,7 +837,8 @@ fail:
+--- src/wps/wps_upnp.c.orig	2020-06-08 14:40:50.402529000 -0700
++++ src/wps/wps_upnp.c	2020-06-08 15:48:08.294830000 -0700
+@@ -861,7 +861,8 @@
  }
  
  
@@ -10,7 +10,19 @@
  #include <sys/sysctl.h>
  #include <net/route.h>
  #include <net/if_dl.h>
-@@ -924,7 +925,8 @@ int get_netif_info(const char *net_if, u
+@@ -950,7 +951,11 @@
+ 				   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;
+ 	}
+ 
+@@ -962,7 +967,8 @@
  		goto fail;
  	}
  	os_memcpy(mac, req.ifr_addr.sa_data, 6);