| player version | 2.8.3 |
| stream type | HLS |
| playback state | 1 |
| duration | 235.023222 |
| current time | 38.55 |
| buffer length | 0.00 |
| average dropped (fps) | 0.00 |
| playback framerate (fps) | 30.00 |
| switching mode | auto |
| transition state | start |
| start index bitrate (B/s) | -0.00k |
| current index bitrate (B/s) | 892.58k |
| current bandwidth (B/s) | 354.34k |
- playlist
- 0:39 / 03:55
- Autoplay: onoff
- fullscreen
OpenFlow, a protocol used widely in software-defined networking (SDN), suffers from a serious security bug: Important authentication and authorization steps are missing from its handshake process.
OpenFlow is maintained by the Open Networking Foundation (ONF) and came about in 2011. It is designed to be a vendor-neutral protocol for managing packet movement between switches and building software-defined networks.
Securing connections and verifying that switches on a network are supposed to be there is an important part of network protocol, and it's one that OpenFlow appears to have overlooked. "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," said Kashyap Thimmaraju of the Technical University of Berlin, one of the discoverers of the bug.
SEE: Quick glossary: Software-defined networking (Tech Pro Research)
What that means is that malicious switches could exploit the inherent trust OpenFlow puts in its networks to cause denial-of-service attacks and to perform covert communications.
To make matters worse, every single version of OpenFlow all the way back to 1.0 is affected. As The Register reported, the ONF hasn't updated OpenFlow specifications since 2015, meaning a fix isn't likely to come quickly.
What this means for OpenFlow users
While the effects of this exploit could be severe there is one major factor that makes it unlikely to see widespread application: It requires the physical connection of a malicious switch on a victim network and a successful TLS connection to a network controller. That doesn't mean it couldn't happen remotely, but it would take a lot of effort to perform such an attack.
The ONF hasn't issued a statement on the OpenFlow vulnerability, and until it does there won't be an official fix available. The team that discovered the bug has published what it said are mitigation steps. All three of the following should be implemented by OpenFlow users:
- Give each switch on your network a unique TLS certificate.
- Whitelist the Datapath Identifiers (DPIDs) of each switch at the controller level and include the switches' public key certificate identifiers as well.
- Make sure controllers are verifying switch DPIDs with each connection.
A business survives when it extends its core competencies in new ways. Increasingly, one of the paths to innovation lies with application programming interfaces (APIs). APIs allow a business to take traditional revenue (and traditional customer and...
TechRepublic will keep an eye out for any statements from the ONF and will update this article with relevant information for OpenFlow network administrators.
The big takeaways for tech leaders:
- OpenFlow network controllers don't require authentication from switches on their networks, which could open up OpenFlow users to denial-of-service attacks and other network exploits. This affects all existing versions of OpenFlow.
- While there is no official patch, OpenFlow users can take action to prevent an attack by requiring all switches to have unique TLS certificates, whitelisting all individual switches on controllers, and forcing controllers to verify switch IDs with each connection.
Also see
- 27 ways to reduce insider security threats (free PDF) (TechRepublic)
- How safe is your air-gapped PC? Attackers can now suck data out via power lines (ZDNet)
- A malicious USB stick could crash your Windows PC, even if it's locked (TechRepublic)
- Digital transformation: think globally, act locally (ZDNet)
- 10 things you should know about deploying a software defined network (TechRepublic)
About Brandon Vigliarolo
Brandon writes about apps and software for TechRepublic. He's an award-winning feature writer who previously worked as an IT professional and served as an MP in the US Army.
Disclosure
Brandon Vigliarolo has nothing to disclose. He does not hold investments in the technology companies he covers.
Full Bio
Brandon writes about apps and software for TechRepublic. He's an award-winning feature writer who previously worked as an IT professional and served as an MP in the US Army.
