neutron

/0 subnet causes dhcp failures

Bug #1362651 reported by Salvatore Orlando
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned
neutron
Fix Released
High
Salvatore Orlando
neutron 2014.2 "juno"

Bug Description

Neutron allow for creating /0 subnet. This alone does not make a lot of sense.

It also causes DHCP failures as the agent is not able to start the dnsmasq process.
Trouble is that the DHCP agent goes into perennial fully resync mode.
This might cause huge delays in setting up DHCP for other subnets, thus resulting in a potential DoS.

So it might be better to prevent /0 subnets at all.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

The OSSA tasks is set to incomplete pending additional review on this issue.

It looks related to https://bugs.launchpad.net/ossa/+bug/1333134... So if the "perennial fully resync mode" is effective, then we should confirm the OSSA task.

Changed in ossa:
status: New → Incomplete
Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :
Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

Thanks Tristan.
I will provide confirmation soon.

Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

In line with the findings for bug 1333134 this will cause the dhcp agent to trace and resync.
this will cause no interruption of service for existing networks but might cause delays for new networks.
The amount of the delay might vary with the number of namespaces deployed on each dhcp agent byut it's not going to be something that causes severe disruption.

Increased agent activity can cause agent crashes. With only 10 network resync brings CPU usage to 20% on a 4 vCPU VM
This can be a disruptive element but in this case probably deployers will have systems to raise alarms and take automated corrective actions.

Summarising, I don't think this is a serious DoS thread, and I reckon the bug can be made public, with the fix going through the usual gerrit channel.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

Thanks for the quick analysis!

Then I don't think this really warrant an OSSA and we should mark this public security and fix it right away.

Salvatore Orlando (salvatore-orlando)
information type: Private Security → Public Security
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/117632

Changed in neutron:
status: New → In Progress
Thierry Carrez (ttx)
Changed in neutron:
milestone: juno-3 → juno-rc1
Tristan Cacqueray (tristan-cacqueray)
Changed in ossa:
status: Incomplete → Won't Fix
Armando Migliaccio (armando-migliaccio)
tags: added: havana-backport-potential icehouse-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/117632
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f2aa93767ece248d8efadc9b3507e233044aa316
Submitter: Jenkins
Branch: master

commit f2aa93767ece248d8efadc9b3507e233044aa316
Author: Salvatore Orlando <email address hidden>
Date: Thu Aug 28 14:54:18 2014 -0700

    Subnets with prefix length 0 are invalid

    This patch changes the API behaviour to return a 400 error
    when a subnet with /0 prefix length is specified.

    This kind of subnet hardly make any sense, and also cannot
    possibly work when DHCP is enabled.

    Change-Id: I8f822f14b91475dcf86ea44ee607013e61cbb6f7
    Closes-Bug: #1362651

Changed in neutron:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in neutron:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: juno-rc1 → 2014.2
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.