Will OpenDaylight 'Lithium' release be safe or bipolar?

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

Will OpenDaylight 'Lithium' release be safe or bipolar?
Will OpenDaylight 'Lithium' release be safe or bipolar?

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.

Page 1 of 2