<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:33:50 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[OPNFLWPLUG-962] Multiple &quot;expired&quot; flows take up the memory resource of CONFIG DS which leads to Controller shutdown.</title>
                <link>https://jira.opendaylight.org/browse/OPNFLWPLUG-962</link>
                <project id="10155" key="OPNFLWPLUG">OpenFlowPlugin</project>
                    <description>&lt;p&gt;#security-status: confirmed&lt;/p&gt;

&lt;p&gt;&lt;ins&gt;&lt;font color=&quot;#ff0000&quot;&gt;Please Note: This issue is a possible security vulnerability, do not discuss outside of this Jira or stage any patches on gerrit until the embargo process reaches that stage.&lt;/font&gt;&lt;/ins&gt;&lt;/p&gt;

&lt;p&gt;I am sending this to you in advance to give us some lead time to triage...&lt;/p&gt;

&lt;p&gt;ISSUE: Multiple &quot;expired&quot; flows take up the memory resource of CONFIG DS&lt;br/&gt;
 which leads to CONTROLLER shutdown.&lt;/p&gt;

&lt;p&gt;STEPS TO REPRODUCE:&lt;/p&gt;

&lt;p&gt;1. Start the controller.&lt;br/&gt;
 2. Connect Openflow swtiches (can use mininet)&lt;br/&gt;
 3. Send multiple different flows with &quot;idle-timeout&quot; and &quot;hard-timeout&quot;&lt;br/&gt;
 set to config store:&lt;br/&gt;
 (http://&amp;lt;CONTROLLER-IP&amp;gt;:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0)&lt;/p&gt;

&lt;p&gt;4. Verify that the OPENFLOWPLUGIN is working fine: Flows are&lt;br/&gt;
 transferred to network and to OPERATIONAL datastore.&lt;br/&gt;
 5. Depending on JVM size, the expired flows are bound to crash the&lt;br/&gt;
 controller&lt;/p&gt;

&lt;p&gt;Karaf crash LOGS are attached&lt;/p&gt;

&lt;p&gt;OBSERVATION:&lt;/p&gt;

&lt;p&gt;Although the installed flows(with timeout set) are removed from network (an thus also from controller&apos;s operations DS), the expired entries are still present in CONFIG DS.This may adhere with the design goals of CONFIG datastore, but, is&lt;br/&gt;
 prone to dangerous attacks on controller.&lt;/p&gt;

&lt;p&gt;The attack can originate both from NORTH or SOUTH. Above description is for north bound attack. A south bound attack can originate when an&lt;br/&gt;
 attacker is attempting a flow flooding attack and since flows come with timeouts, the attack is not successful. However, the attacker will now&lt;br/&gt;
 be successful in CONTROLLER overflow attack(resource consumption). This is more severe and dangerous than the actual flow-table-flooding attack.&lt;/p&gt;

&lt;p&gt;Although, the network(actual flow tables) and operational DS are only (~)1% occupied, the controller shouts for resource consumption. This happens because the installed flows get removed from the network upon timeout.&lt;/p&gt;

&lt;p&gt;The error is not recoverable and shuts down the controller.&lt;/p&gt;

&lt;p&gt;MITIGATION:&lt;/p&gt;

&lt;p&gt;The expired flows should be removed from controller&apos;s CONFIG datastore.&lt;/p&gt;

&lt;p&gt;If the design goal is to keep the flow entries persistent, there should be a threshold which should be calculated truly based on JVM&apos;s heap size.&lt;/p&gt;

&lt;p&gt;Another thought: it makes sense to have operational DS (active state of nw) contain only those many tables as present in the network, the CONFIG DS(desired state) can have different size which can be scaled up and scaled down depending on resource usage.&lt;/p&gt;</description>
                <environment></environment>
        <key id="28930">OPNFLWPLUG-962</key>
            <summary>Multiple &quot;expired&quot; flows take up the memory resource of CONFIG DS which leads to Controller shutdown.</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.opendaylight.org/images/icons/priorities/critical.svg">High</priority>
                        <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10001">Won&apos;t Do</resolution>
                                        <assignee username="Avishnoi">Anil Vishnoi</assignee>
                                    <reporter username="vhd">Vaibhav Hemant Dixit</reporter>
                        <labels>
                    </labels>
                <created>Thu, 30 Nov 2017 16:05:36 +0000</created>
                <updated>Tue, 16 Jan 2018 15:52:41 +0000</updated>
                            <resolved>Tue, 16 Jan 2018 15:52:41 +0000</resolved>
                                                    <fixVersion>Carbon-SR3</fixVersion>
                    <fixVersion>Nitrogen-SR2</fixVersion>
                    <fixVersion>Oxygen</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                                                                                <comments>
                            <comment id="60298" author="tpantelis" created="Thu, 30 Nov 2017 16:12:29 +0000"  >&lt;p&gt;This is an openflowplugin issue and should be moved to that project.&lt;/p&gt;</comment>
                            <comment id="60322" author="lukehinds" created="Mon, 4 Dec 2017 10:43:33 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=abhijit2511&quot; class=&quot;user-hover&quot; rel=&quot;abhijit2511&quot;&gt;abhijit2511&lt;/a&gt; could you triage this please (i.e. confirm its a security issue). After that we need to decide if it requires a code fix, or an architecture recommendation (run on a secluded network, behind a proxy (rate limiting) etc.&lt;/p&gt;</comment>
                            <comment id="60342" author="abhijit2511" created="Tue, 5 Dec 2017 19:43:07 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Avishnoi&quot; class=&quot;user-hover&quot; rel=&quot;Avishnoi&quot;&gt;Avishnoi&lt;/a&gt; - can you please take a look at this?&lt;/p&gt;</comment>
                            <comment id="60359" author="lukehinds" created="Thu, 7 Dec 2017 12:13:52 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Avishnoi&quot; class=&quot;user-hover&quot; rel=&quot;Avishnoi&quot;&gt;Avishnoi&lt;/a&gt; could you start by triaging (confirm its an issue), so we can then set the security status to `confirmed`&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;This is what I posted to the security list:&lt;/p&gt;

&lt;p&gt;&#160;&lt;br/&gt;
&lt;em&gt;I think we could cover both issue&apos;s as an advisory that the plugins API should only be listening on an internal network and / or coupled with a rate limiting proxy or web application firewall. I have found that once attempts are made to resolve DOS attacks within the app itself, it can become a case of going down the rabbit hole and sets an expectation of inherent robust capabilities always being present.&lt;/em&gt;&lt;br/&gt;
&#160;__&#160;&lt;br/&gt;
&lt;em&gt;The plugin PTL is yet to triage, but I would OK with a nofix and we send out details of the exploits and a recommendation of leveraging a security tier around the API.&lt;/em&gt;&lt;/p&gt;</comment>
                            <comment id="60366" author="vishnoianil@gmail.com" created="Fri, 8 Dec 2017 08:42:39 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=lukehinds&quot; class=&quot;user-hover&quot; rel=&quot;lukehinds&quot;&gt;lukehinds&lt;/a&gt; I will look at the issue tomororw.&lt;/p&gt;</comment>
                            <comment id="60372" author="vishnoianil@gmail.com" created="Sat, 9 Dec 2017 01:21:10 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=lukehinds&quot; class=&quot;user-hover&quot; rel=&quot;lukehinds&quot;&gt;lukehinds&lt;/a&gt; Keeping the configuration in config data store is by design for OpenDaylight controller, because data present in the config data store is user configuration and controller should not remove the configuration on it&apos;s own, because that breaks the contract with the it&apos;s consumer. Removing this configuration is users responsibility. Now it&apos;s a valid scenario that it can be leveraged for the DOS attack by exhausting the memory resources. But this problem is not specific to openflowplugin project, it&apos;s a general issue with the base ODL datastore.&#160;Exhausting memory through flows is a one possible scenario. User can push millions of flow with timeout value and that can also cause the crash. So&#160;root of the vulnerability is that user can exhaust data store memory by pushing lot of configuration and it requires some preventive mechanism in place.&#160; This is something that need to be handled by the Controller project as it owns the data store component. Can you please move the issue to the Controller project for their attention.&#160;&lt;/p&gt;</comment>
                            <comment id="60374" author="lukehinds" created="Sun, 10 Dec 2017 17:16:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Avishnoi&quot; class=&quot;user-hover&quot; rel=&quot;Avishnoi&quot;&gt;Avishnoi&lt;/a&gt; this was originally lodged under the controller project, but &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt; stated it was an openflow-plugin issue and not the controllers so we moved the Jira. With that in mind I don&apos;t want to switch it back again. Instead we should resolve its rightful home in this comment thread and it can be moved / remain when a consensus is met. I cannot be arbiter here as I don&apos;t know&#160; both projects well enough, so will ask &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt&quot; class=&quot;user-hover&quot; rel=&quot;skitt&quot;&gt;skitt&lt;/a&gt; and anyone else from the SRT to help mediate where the issue should be fixed.&lt;/p&gt;</comment>
                            <comment id="60419" author="vishnoianil@gmail.com" created="Tue, 12 Dec 2017 09:22:28 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis&quot; class=&quot;user-hover&quot; rel=&quot;tpantelis&quot;&gt;tpantelis&lt;/a&gt; &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt; Tom/Robert, the&#160;attack here is basically exhausting the data store by pushing lot of data (this can be openflowplugin data or it can be any other data from other southbound plugin/applications etc). So in my opinion the preventive mechanism is required at the data store level and not at the individual consumer level. Please let me know your thoughts.&lt;/p&gt;</comment>
                            <comment id="60434" author="skitt@redhat.com" created="Tue, 12 Dec 2017 13:09:37 +0000"  >&lt;p&gt;I don&#8217;t think we can ever find effective mitigation measures &lt;b&gt;inside&lt;/b&gt; OpenDaylight against DoS attacks in general. Given that ODL is only supposed to be deployed in segregated networks anyway (at least, only have its admin accessible from an admin network), I&#8217;m not sure we really need to do anything more (beyond documenting this better perhaps).&lt;/p&gt;</comment>
                            <comment id="60455" author="rovarga" created="Wed, 13 Dec 2017 07:52:54 +0000"  >&lt;p&gt;At the high level, the deployment needs to be sized to support the expected workload &#8211; the datastore can hardly make that decision based on what it observes inside the JVM, simply because it does not know what exactly runs in the JVM.&lt;/p&gt;

&lt;p&gt;From the datastore perspective, it is asked to hold some state &#8211; and it does so. The datastore does not have a concept of data expiring &#8211; this is something that is specific to the OFP model. It therefore falls to either the user or OFP to prune this expired state. I believe this can be easily achieved in FRM during reconciliation &#8211; it has to understand that a flow is already expired and should not be pushed to the switch anyway.&lt;/p&gt;</comment>
                            <comment id="60456" author="vishnoianil@gmail.com" created="Wed, 13 Dec 2017 08:47:54 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt; You are assuming here&#160;the only scenario where it&apos;s possible that there is some expired data present in the data store. But there are&#160;very likely&#160;scenarios where all the data present in the data store is valid configuration. Also this holds true not only for the openflowplugin but all the consumer (southbound, northbound, applications) of the data store.&lt;/p&gt;

&lt;p&gt;From openflowplugin perspective, FRM reconciliation only triggers for specific switch when that switch connects to the&#160;controllers, so&#160;that is not really a good trigger point for the pruning because switch might not disconnect for long duration.&#160;Moreover we can&apos;t just remove user configuration, just because a configuration is removed from the switch for valid reasons. Openflowplugin uses operational data store to notify the user about&#160;removal of the configuration from switch, so it&apos;s up to the application now to prune the data store.&#160;&lt;/p&gt;

&lt;p&gt;Just for a sake of assumption, we assume that openflowplugin does some pruning, but what if user is using openflowplugin with bgp/pcep plugin and&#160;that start consuming memory for valid reason.&#160;In that scenario, OFP pruning won&apos;t help because controller can still hit the same issue and OFP won&apos;t have any control over it as well.&lt;/p&gt;

&lt;p&gt;Given that this security vulnerability can be used to attack by dumping lot of data to the data store through rest, one simple mechanism can be implemented in the controller is to&#160;expose a configuration parameter to user, where use can set a % of heap utilization when data store stop taking any more transaction and throw exception to the application. That can be a deterministic trigger point for applications as well for doing any possible pruning they can do.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Overall to address this vulnerability i can see only two possible solutions, either we can do what Stephen suggested above&#160;and make it users responsibility OR controller should&#160;implement some mechanism on the line of&#160;example i provided above.&#160;&lt;/p&gt;</comment>
                            <comment id="60477" author="lukehinds" created="Thu, 14 Dec 2017 16:02:20 +0000"  >&lt;p&gt;So my thoughts here are that any rate limiting / flow control should take place in the &apos;front&apos; regions of an applications architecture , rather than in any back end such as a database, meta store etc.&lt;/p&gt;

&lt;p&gt;So with that I think we should notify operators of the vulnerability and make two recommendations as well:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;All REST interfaces should be on private / trusted internal networks.&lt;/li&gt;
	&lt;li&gt;The above if desired can be further bolstered by implementation of a rate limiting proxy (repose, haproxy, nginx, mod_ratelimit etc) or web application firewall.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;If no objections I will put a draft together, and we can review in here before posting?&lt;/p&gt;</comment>
                            <comment id="60494" author="lukehinds" created="Fri, 15 Dec 2017 13:16:25 +0000"  >&lt;p&gt;ok all, I have the following. Once there is an OK from one srt member and &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Avishnoi&quot; class=&quot;user-hover&quot; rel=&quot;Avishnoi&quot;&gt;Avishnoi&lt;/a&gt; I will send this note out to downstream stakeholders.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Multiple &quot;expired&quot; flows take up the memory resource of CONFIG DS which leads to Controller shutdown.&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;The following issue was discovered and reported by Vaibhav Hemant Dixit.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Summary&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Multiple &quot;expired&quot; flows take up the memory resource of CONFIG DATASTORE which leads to CONTROLLER shutdown.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Affected Services / Software&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;OpenFlow Plugin and OpenDayLight Controller.&lt;/p&gt;

&lt;p&gt;Versions: Nitrogen, Carbon, Boron&#160;&#160; &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt;, &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Avishnoi&quot; class=&quot;user-hover&quot; rel=&quot;Avishnoi&quot;&gt;Avishnoi&lt;/a&gt; -&amp;lt; please verify versions affected (back to depreciated releases).&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Discussion&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;If multiple different flows with &quot;idle-timeout&quot; and &quot;hard-timeout&quot; 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.&lt;/p&gt;

&lt;p&gt;Although the installed flows(with timeout set) are removed from network (an thus also from controller&apos;s operations DS), the expired entries are still present in CONFIG DS.&lt;/p&gt;

&lt;p&gt;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).&lt;/p&gt;


&lt;p&gt;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.&lt;/p&gt;


&lt;p&gt;&lt;b&gt;Recommended Actions&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Management API&#8217;s within OpenDayLight should only ever be deployed within a segregated private network and never exposed to public networks, this includes the OpenFlowPlugin. Further protections can be implemented by deploying a rate limiting proxy (such as OpenRepose, HAProxy, nginx, mod_ratelimit etc) or web application firewall.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="60516" author="lukehinds" created="Tue, 19 Dec 2017 11:49:31 +0000"  >&lt;p&gt;ok, three days have passed so will take the radio silence as a consensus to go with the above. this will be sent to downstream stakeholders on Tuesday the 9th of January to allow operators to get passed the seasonal shutdown some will have.&lt;/p&gt;</comment>
                            <comment id="60731" author="lukehinds" created="Tue, 16 Jan 2018 15:20:04 +0000"  >&lt;p&gt;This is now open with notification sent to stakeholder and public lists. &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vhd&quot; class=&quot;user-hover&quot; rel=&quot;vhd&quot;&gt;vhd&lt;/a&gt; please close now.&lt;/p&gt;</comment>
                            <comment id="60734" author="vhd" created="Tue, 16 Jan 2018 15:36:07 +0000"  >&lt;p&gt;Marking the bug as closed.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="14313" name="karaf.log" size="505349" author="lukehinds" created="Thu, 30 Nov 2017 16:06:59 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i038mn:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>