17:00 Cy Schubert (cy) 

security/wpa_supplicant: Update to 2.10

The long awaited hostapd 2.10 is finally here.

    d3564c5

05:48 cy 

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

 

20:45 marino 

security/wpa_supplicant: Upgrade version 2.3 => 2.4

See http://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog for list
of changes since version 2.3.

 

21:20 marino 

Revive security/wpa_supplicant after 6.5 years => version 2.3

This port was retired at version 0.3.8 because wpa_supplicant is
part of FreeBSD base.  However, the last few releases have had a period
of only a few months, so the base is always going to be behind.  DragonFly
is also affected, so I'm bringing the port back at the latest version.

It features the same patches as FreeBSD including the conversion to use
libutil's pidfile routines.  There are some additional patches for
DragonFly support and to fix some bugs from the 9 Oct 2014 release.

The WPA Supplicant build system has been converted to ports options, and
there are dozens of them.  I've set the defaults to match the
configuration in base and verified that it builds with all options
selected at once.