Resource Exhaustion Affecting opendaylight package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.08% (37th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Resource Exhaustion vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL7-OPENDAYLIGHT-5244992
  • published27 Mar 2023
  • disclosed16 Jan 2018

Introduced: 16 Jan 2018

CVE-2017-1000411  (opens in a new tab)
CWE-400  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:7 opendaylight.

NVD Description

Note: Versions mentioned in the description apply only to the upstream opendaylight package and not the opendaylight package as distributed by RHEL. See How to fix? for RHEL:7 relevant fixed versions and status.

OpenFlow Plugin and OpenDayLight Controller versions Nitrogen, Carbon, Boron, Robert Varga, Anil Vishnoi contain a flaw when multiple 'expired' flows take up the memory resource of CONFIG DATASTORE which leads to CONTROLLER shutdown. If multiple different flows with 'idle-timeout' and 'hard-timeout' are sent to the Openflow Plugin REST API, the expired flows will eventually crash the controller once its resource allocations set with the JVM size are exceeded. Although the installed flows (with timeout set) are removed from network (and thus also from controller's operations DS), the expired entries are still present in CONFIG DS. The attack can originate both from NORTH or SOUTH. The above description is for a north bound attack. A south bound attack can originate when an attacker attempts a flow flooding attack and since flows come with timeouts, the attack is not successful. However, the attacker will now be successful in CONTROLLER overflow attack (resource consumption). Although, the network (actual flow tables) and operational DS are only (~)1% occupied, the controller requests for resource consumption. This happens because the installed flows get removed from the network upon timeout.