[<prev] [next>] [day] [month] [year] [list]
Message-ID: <df84809c-8192-2855-c0ea-2b609d176aa8@sect.tu-berlin.de>
Date: Wed, 9 May 2018 11:48:40 +0200
From: Kashyap Thimmaraju <kashyap.thimmaraju@...t.tu-berlin.de>
To: oss-security@...ts.openwall.com
Cc: Stefan Schmid <schmiste@...il.com>, Liron Schiff
<schiff.liron@...il.com>, Brian O'Connor <bocon@...nnetworking.org>
Subject: CVE-2018-1000155: Denial of Service, Improper Authentication and
Authorization, and Covert Channel in the OpenFlow 1.0+ handshake
Hello Everybody,
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.
Credit:
Kashyap Thimmaraju (Technische Universität Berlin), Robert Krösche
(Technische Universität Berlin), Liron Schiff (GuardiCore Labs) and
Stefan Schmid (University of Vienna)
--
Thanks,
Kashyap Thimmaraju <kashyap.thimmaraju@...t.tu-berlin.de>
Security in Telecommunications <sect.tu-berlin.de>
Technische Universität Berlin
Ernst-Reuter-Platz 7, Sekr TEL 17
10587 Berlin, Germany
Phone: +49 30 8353 58351
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
