The following CVE was raised against the OpenFlow Plugin, but we were informed after it went public, so creating this as an open Jira ticket with no security context label to keep it private:

http://www.openwall.com/lists/oss-security/2018/05/09/4

 We have identified issues with a popular Software-Defined Networking protocol, OpenFlow. Below are the details of the vulnerabilities. OpenFlow controller implementations should strongly consider addressing these issues, and OpenFlow adopters should be aware of such security risks.

CVE-2018-1000155: Denial of Service, Improper Authentication and Authorization, and Covert Channel in the OpenFlow handshake Severity:

Important Vendor: Open Networking Foundation (ONF), OpenFlow controllers

Versions Affected: OpenFlow specification 1.0 onwards

Description: The OpenFlow handshake does not require the controller to authenticate switches during the OpenFlow handshake. Furthermore, the controller is not required to authorize switches access to the controller. The absence of authentication and authorization in the OpenFlow handshake allows one or more malicious switches connected to an OpenFlow controller to cause Denial of Service attacks in certain OpenFlow controllers by spoofing OpenFlow switch identifiers known as DataPath Identifiers (DPIDs). Additionally, the lack of authentication and authorization in the OpenFlow handshake can be exploited by malicious switches for covert communications, bypassing data plane (and potentially control plane) security mechanisms. In particular, the OpenFlow "Features Reply" message sent by the switch is inherently trusted by the controller. Note that for the attacker to launch an attack, the OpenFlow switch must first establish a (secure) transport connection with the OpenFlow controller (e.g., TLS and TCP), and the switch must be controlled by the attacker.

Mitigation: The attack can be deterred if OpenFlow connections are secured via the following hardened authentication scheme: Unique TLS certificates for switches, white-list of switch DPIDs at controllers which also includes the switches’ respective public-key certificate identifier, and lastly a controller mechanism that verifies the DPID announced in the OpenFlow handshake is over the TLS connection with the associated (DPID) certificate.

 A patch was developed and released by onos: https://github.com/opennetworkinglab/onos/commit/f69e3e34092139600404681798cebeefebcfa6c6

Credit: Kashyap Thimmaraju (Technische Universität Berlin), Robert Krösche (Technische Universität Berlin), Liron Schiff (GuardiCore Labs) and Stefan Schmid (University of Vienna)