Will OpenDaylight 'Lithium' release be safe or bipolar?

News by Adrian Bridgwater

OpenDaylight's troubles highlight the problems with security in the open source world ahead of Lithium release.

OpenDaylight has been in the wars. Network engineers will now be looking to assess whether the project's network programmability technology for Software Defined Networks (SDN) and Network Functions Virtualisation (NFV) is suitable for public consumption.

An initiative spawning from the Linux Foundation, OpenDaylight recently suffered a vulnerability that saw its open source Netdump kernel transport protocol exposed to remote takeover.

Six-month gestation/infestation period

What will worry some is that the Netdump security issue went unfixed for six months when other open source related vulnerabilities (such as Heartbleed and Shellshock) saw the community work more rapidly to form a defined process and team to deal with the problem.

Now is a crucial time for OpenDaylight as its community is reported to be currently working on its third software release (called Lithium) which will be made available later this year. Lithium continues to integrate components to solve what the project team envisages will be a range of use cases for enterprises and service providers such as networking virtualisation, network management, monitoring and security.

Although clinical depression is still a possibility, there may be something of an antidote on the way.

Software-defined interconnection technology company IIX Inc has recently joined the OpenDaylight Project and the firm's product security engineer David Jorm has stepped forward and taken a leadership role in forming and operating OpenDaylight's security response team.

Building the defences

The team has adopted a formalised process that allows the team to capture the report of an issue in private and keep it embargoed until patched builds are available. It has been able to apply this process successfully for a far less critical flaw in OpenDaylight's defense4all project.

“The OpenDaylight security response team is now set up to function on par with other large open source projects such as OpenStack and projects under the Apache Software Foundation's umbrella,” said Jorm. “Our next step is to establish a proactive secure engineering process that minimises the risk of security issues entering the code base in the first place.”

Netdump was a flaw in OpenDaylight's XML processing code. Jorm describes the flaw as “very common” across all applications, but particularly those written in Java. The code failed to restrict the resolution of external entities in XML documents provided by callers to OpenDaylight's XML-based APIs. Attackers could exploit this flaw by sending XML document to OpenDaylight that include external entities pointing to files on the server's disk, which would then be read and returned to the attacker.

As we know, one of the reasons Java has been so popular is its huge ecosystem of components and libraries which allows developers to build complex applications quickly, with third-party libraries doing the heavy lifting. However, many of the techniques used to abstract heavy lifting out to libraries have serious security drawbacks. This leads to a second problem: when an application is built using dozens of libraries, there isn't an easy mechanism that lets developers know they need to update a library to apply a security patch. While at Red Hat Jorm contributed to the victims (victi.ms) project, which aims to provide a completely open source solution to this problem.

Jorm sees two big challenges for open source security. One is coordinating the disclosure of vulnerabilities and the other is minimising the risk of security issues entering the code base in the first place. “Proprietary software vendors have been successful at addressing these challenges, but we can't just copy the proprietary model to fix this problem. We need to develop a robust mechanism that is compatible with the open source model,” he said.

What open source does next

So it appears that the recent slew of open source vulnerabilities has obviously galvanised some communities to establish more formalised action groups and working bodies to deal with security issues. If open source has had its reputation tarnished to some degree then this is arguably no worse a ‘drubbing' than is typically received by any other platform on a weekly basis.

What matters now is how deep firms decide to implement open source solutions and whether they afford open technologies the respect of a fully robust enterprise level solution. Without open source security there is no productive enterprise open source and in evolutionary terms that's bad news for everyone.

Topics:
Security

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events