[OSSA-2016-009] Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363)

[Dustin Lundquist]

The IptablesFirewallDriver does not prevent spoofing other instances or a routers MAC and/or IP addresses. The rule to permit DHCP discovery and request messages:

        ipv4_rules += [comment_rule('-p udp -m udp --sport 68 --dport 67 '
                                    '-j RETURN', comment=ic.DHCP_CLIENT)]

is too permissive, it does not enforce the source MAC or IP address. This is the IPv4 case of public bug https://bugs.launchpad.net/neutron/+bug/1502933, and a solution was previously mentioned in June 2013 in https://bugs.launchpad.net/neutron/+bug/1427054.

If L2population is not used, an instance can spoof the Neutron router's MAC address and cause the switches to learn a MAC move, allowing the instance to intercept other instances traffic potentially belonging to other tenants if this is shared network.

The solution for this is to permit this DHCP traffic only from the instance's IP address and the unspecified IPv4 address 0.0.0.0/32 rather than from an IPv4 source, additionally the source MAC address should be restricted to MAC addresses assigned to the instance's Neutron port.

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Armando Migliaccio (armando-migliaccio)]

Looking.

[Armando Migliaccio (armando-migliaccio)]

I think the issue exists, and under the circumstances identified there's the risk to intercept traffic on a shared medium. If the solution wouldn't involve tracking the source mac of all instances on the shared network, I'd say go for it, but the scalability implications concern me. Having said that, I think knowledge about this is already public domain because of the other issues being reported, therefore we may want to consider open the discussion for wider feedback.

[Tristan Cacqueray (tristan-cacqueray)]

Thank you Armando for the investigation.

It's still unclear whenever shared network impacts do warrants an advisory.
If nobody objects, lets make this bug report public security.

Also, should the description be saying "the IPv6* case of public bug" instead of IPv4 ?

[Dustin Lundquist (dlundquist)]

Tristan,

It's reasonable to assume IPv4 is much more widely deployed than IPv6, so the public IPv6 bug a significantly smaller number of installations. That being said, it wasn't a very difficult to examine the IPv4 case for the same vulnerability as the IPv6 case, so don't believe there is significant value in maintaining the embargo.

Armando,

Neutron presently maintains an ebtables chain for each instance port to prevent MAC spoofing, the overhead of expanding this to validate all source MAC as well as ARP messages is one additional rule in this chain (ebtables allows matching against multiple MAC addresses in a single rule). If Neutron chooses not to address this, first-hop security expectations should to be clearly defined in a policy somewhere so operators can make informed decisions on how they deploy Neutron.

[Kevin Benton (kevinbenton)]

I agree that this is something we need to address. I'm fine with it being opened to the public or being fixed first.

@Dustin,

Can you confirm that the attached patch fixes the mac spoofing issue? (Note that there are two patches in there, one for Linux Bridge and one for OVS)

I didn't do anything about the DHCP request source IP restriction in this patch because that one just seems to be a way to spam some DHCP requests for an incorrect address. Correct me if I'm wrong, but that doesn't pose any security issue (other than log noise), right?

[Dustin Lundquist (dlundquist)]

@Kevin,

I've tested the patch on ML2 LinuxBridge, and in the process of testing on ML2 OVS now. I'm not positive that all potential instance operating systems would not insert an entry its ARP table after receiving a unicast UDP packet, although I've verified Linux does not learn neighbors from unicast UDP packets. I think we can remove the embargo once this patch is merged.

[Dustin Lundquist (dlundquist)]

@Kevin

I've verified your patch prevents MAC address spoofing with both LinuxBridge and OVS mechanism drivers. The chunk in update_stale_ofport_rules didn't apply cleanly to master, but was trivial to resolve by hand.

[Jeremy Stanley (fungi)]

I agree the impact of this bug should be limited enough that it's worthwhile to work it in public and avoid complexities of the embargo process.

[Tristan Cacqueray (tristan-cacqueray)]

@Dustin @Kevin, if it's ok for you, can you remove the privacy setting of this bug before submitting the proposed patch to gerrit ?

[Dustin Lundquist (dlundquist)]

@Tristan @Jeremy, The MAC spoofing aspect of this could based used to DoS or intercept other tenants in a public cloud using shared networks. I'm not familiar with the review process for a patch under embargo, but releasing this could leave public deployments exposed. On the other hand, as I mentioned in the original bug report, this is the IPv4 case of a public IPv6 bug and a fix was first suggested in 2013. Hopefully public deployments have taken additional precautions to harden their environments.

[Jeremy Stanley (fungi)]

In the past we've considered some bugs only impacting shared tenant networks to be impractical vulnerabilities given the warnings in the security guide about shared network deployment models (though I'm failing to find specific precedent bugs to cite at the moment). That said, if the proposed patch fixes this and can be backported quickly to supported stable branches (mitaka, liberty, kilo) without an adverse behavior change then we could follow embargo process. I'm just wary, as the related IPv6 bug has been public for months with no movement.

[Kevin Benton (kevinbenton)]

I would be okay with a public release and then regular code review. It should be relatively quick since the patch is already prepared with tests.

[Jeremy Stanley (fungi)]

I've switched this to public security. Changes can be pushed to public Gerrit while we continue to debate the impact and need for an advisory.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/299023

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/299024

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/299025

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/299026

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/299027

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/299028

[OpenStack Infra (hudson-openstack)]

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

[Tristan Cacqueray (tristan-cacqueray)]

About the OSSA status, is the impact for non shared network limited to single tenant scope (e.g. one instance can bypass neutron anti-spoof rules toward other instances of the same tenant only) ?

[OpenStack Infra (hudson-openstack)]

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

commit be298f8bc35e6d006c7a9361e42755c9d6790e1e
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 02:45:11 2016 -0700

    Linux Bridge: Add mac spoofing filtering to ebtables

    The current mac-spoofing code in iptables has two issues.
    First, it occurs after the address discovery allow rules
    (e.g. DHCP), so MAC addresses can be spoofed on discovery
    protocols. Second, since it is based on iptables, it
    doesn't apply to protocols like STP.

    This means a VM could generate one of these types of packets
    with a spoofed MAC address to trick switches into learning
    that the spoofed MAC now belongs to the VM's port. The impact
    of this depends on the configuration of the environment
    (e.g. use of L2pop: see the bug report for details).

    This patch adds MAC spoofing filtering to the ARP protection
    code for Linux bridge based on ebtables. Only traffic sourced
    from the MAC address on the port or in the allowed address
    pair MACs will be allowed.

    This filtering will not be enabled if the port has port
    security disabled or if the device_owner starts with 'network:'.

    Change-Id: I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78
    Partial-Bug: #1558658

[Tristan Cacqueray (tristan-cacqueray)]

Covering both bug 1558658 and bug 1502933, here is impact description draft #1.
Is this accurate enough ?

Title: Neutron anti-spoof protection bypass
Reporter: Romain Aviolat (Nagravision) and Dustin Lundquist (Blue Box Group)
Products: Neutron
Affects: >=2015.1.0 <=2015.1.3, >=7.0.0 <=7.0.4, <=8.0.0

Description:
Romain Aviolat from Nagravision and Dustin Lundquist from Blue Box Group, Inc independently reported a vulnerability in Neutron anti-spoof protection. By forging discovery protocol source address, an instance may spoof addresses on attached network resulting in Denial of Service and/or traffic interception. When L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

[Dustin Lundquist (dlundquist)]

@Tristan, A few suggestions for impact description:
  1. s/forging discovery protocol source address/forging DHCP discovery source address/ (DHCP is the protocol, discovery is the message type, and could be confused with IPv6 neighbor discovery protocol).
  2. In bug/1558674 I generalized this to all non-IP traffic, I think this is relevant to the impact description since it is a more likely attack vector
  3. We should mention that both MAC and IP source spoofing where permitted. MAC spoofing effects are limited to local network, while IP spoofing could be used for either a direct DoS or interfering with DHCP leases on other networks.

[Tristan Cacqueray (tristan-cacqueray)]

Thank you Dustin for this review! How about:

By forging non-IP traffic such as DHCP discovery or ARP messages, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

[Dustin Lundquist (dlundquist)]

Still a bit muddled, DHCP is IP traffic, and ARP is already filtered by ebtables. How about:

By forging DHCP discovery messages or non-IP traffic, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/301977

[Tristan Cacqueray (tristan-cacqueray)]

Oups, dhcp discovery is indeed IP. Thank you for the correction.

https://review.openstack.org/301977 is the proposed OSSA, note that it is missing backports of the icmpv6 extra rules.
I'll request the CVE number once everything is ready.

[OpenStack Infra (hudson-openstack)]

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

commit 997d7b03fb7f5528f0a3ce70867b9dcd9321509e
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 04:47:28 2016 -0700

    OVS: Add mac spoofing filtering to flows

    The mac-spoofing filtering done by iptables was
    not adequate. See the bug report and change
    I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78 for
    more information.

    This patch adds flows to the OVS agent to block
    any traffic from the VM that isn't in the allowed
    address pairs macs or the mac address field of
    the port.

    Closes-Bug: #1558658
    Change-Id: I02984b21872e0f183db7404c10d8180dbd89075f

[OpenStack Infra (hudson-openstack)]

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

commit 6a93ee8ac1a901c255e3475a24f1afc11d8bf80f
Author: Dustin Lundquist <email address hidden>
Date: Thu Mar 31 12:04:31 2016 -0700

    Iptables firewall prevent IP spoofed DHCP requests

    The DHCP rules in the fixed iptables firewall rules were too permissive.
    They permitted any UDP traffic with a source port of 68 and destination
    port of 67. Care must be taken since these rules return before the IP
    spoofing prevention rules. This patch splits the fixed DHCP rules into
    two, one for the discovery and request messages which take place before
    the instance has bound an IP address and a second to permit DHCP
    renewals.

    Change-Id: Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5
    Partial-Bug: #1558658

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/303563

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/303572

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/303617

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/303563
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5853af9cba6733725d6c9ac0db644f426713f0cf
Submitter: Jenkins
Branch: stable/mitaka

commit 5853af9cba6733725d6c9ac0db644f426713f0cf
Author: Dustin Lundquist <email address hidden>
Date: Thu Mar 31 12:04:31 2016 -0700

    Iptables firewall prevent IP spoofed DHCP requests

    The DHCP rules in the fixed iptables firewall rules were too permissive.
    They permitted any UDP traffic with a source port of 68 and destination
    port of 67. Care must be taken since these rules return before the IP
    spoofing prevention rules. This patch splits the fixed DHCP rules into
    two, one for the discovery and request messages which take place before
    the instance has bound an IP address and a second to permit DHCP
    renewals.

    Change-Id: Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5
    Partial-Bug: #1558658
    (cherry picked from commit 6a93ee8ac1a901c255e3475a24f1afc11d8bf80f)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/303572
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fd5fd259a02156babdfcb12f66cde6ec9e7274ae
Submitter: Jenkins
Branch: stable/liberty

commit fd5fd259a02156babdfcb12f66cde6ec9e7274ae
Author: Dustin Lundquist <email address hidden>
Date: Thu Mar 31 12:04:31 2016 -0700

    Iptables firewall prevent IP spoofed DHCP requests

    The DHCP rules in the fixed iptables firewall rules were too permissive.
    They permitted any UDP traffic with a source port of 68 and destination
    port of 67. Care must be taken since these rules return before the IP
    spoofing prevention rules. This patch splits the fixed DHCP rules into
    two, one for the discovery and request messages which take place before
    the instance has bound an IP address and a second to permit DHCP
    renewals.

    Conflicts:
     neutron/tests/functional/agent/test_firewall.py

    Change-Id: Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5
    Partial-Bug: #1558658
    (cherry picked from commit 6a93ee8ac1a901c255e3475a24f1afc11d8bf80f)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/303617
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b0f6984de3985b80c728dd282fe6148b28f01fe4
Submitter: Jenkins
Branch: stable/kilo

commit b0f6984de3985b80c728dd282fe6148b28f01fe4
Author: Dustin Lundquist <email address hidden>
Date: Thu Mar 31 12:04:31 2016 -0700

    Iptables firewall prevent IP spoofed DHCP requests

    The DHCP rules in the fixed iptables firewall rules were too permissive.
    They permitted any UDP traffic with a source port of 68 and destination
    port of 67. Care must be taken since these rules return before the IP
    spoofing prevention rules. This patch splits the fixed DHCP rules into
    two, one for the discovery and request messages which take place before
    the instance has bound an IP address and a second to permit DHCP
    renewals.

    Conflicts:
     neutron/agent/linux/iptables_firewall.py
     neutron/tests/functional/agent/test_firewall.py
     neutron/tests/unit/agent/linux/test_iptables_firewall.py
     neutron/tests/unit/agent/test_securitygroups_rpc.py

    Change-Id: Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5
    Partial-Bug: #1558658
    (cherry picked from commit 6a93ee8ac1a901c255e3475a24f1afc11d8bf80f)

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dave Walker (<email address hidden>) on branch: stable/kilo
Review: https://review.openstack.org/299027
Reason:
stable/kilo closed for 2015.1.4

This release is now pending its final release and no freeze exception has
been seen for this changeset. Therefore, I am now abandoning this change.

If this is not correct, please urgently raise a thread on openstack-dev.

More details at: https://wiki.openstack.org/wiki/StableBranch

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dave Walker (<email address hidden>) on branch: stable/kilo
Review: https://review.openstack.org/299028
Reason:
stable/kilo closed for 2015.1.4

This release is now pending its final release and no freeze exception has
been seen for this changeset. Therefore, I am now abandoning this change.

If this is not correct, please urgently raise a thread on openstack-dev.

More details at: https://wiki.openstack.org/wiki/StableBranch

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299025
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b57d9fa96967de4aa634fb32a683d6c37fd05fab
Submitter: Jenkins
Branch: stable/liberty

commit b57d9fa96967de4aa634fb32a683d6c37fd05fab
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 02:45:11 2016 -0700

    Linux Bridge: Add mac spoofing filtering to ebtables

    The current mac-spoofing code in iptables has two issues.
    First, it occurs after the address discovery allow rules
    (e.g. DHCP), so MAC addresses can be spoofed on discovery
    protocols. Second, since it is based on iptables, it
    doesn't apply to protocols like STP.

    This means a VM could generate one of these types of packets
    with a spoofed MAC address to trick switches into learning
    that the spoofed MAC now belongs to the VM's port. The impact
    of this depends on the configuration of the environment
    (e.g. use of L2pop: see the bug report for details).

    This patch adds MAC spoofing filtering to the ARP protection
    code for Linux bridge based on ebtables. Only traffic sourced
    from the MAC address on the port or in the allowed address
    pair MACs will be allowed.

    This filtering will not be enabled if the port has port
    security disabled or if the device_owner starts with 'network:'.

    Change-Id: I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78
    Partial-Bug: #1558658
    (cherry picked from commit be298f8bc35e6d006c7a9361e42755c9d6790e1e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299026
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b33c16bb0e75015f3e75693d815cfd616c831112
Submitter: Jenkins
Branch: stable/liberty

commit b33c16bb0e75015f3e75693d815cfd616c831112
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 04:47:28 2016 -0700

    OVS: Add mac spoofing filtering to flows

    The mac-spoofing filtering done by iptables was
    not adequate. See the bug report and change
    I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78 for
    more information.

    This patch adds flows to the OVS agent to block
    any traffic from the VM that isn't in the allowed
    address pairs macs or the mac address field of
    the port.

    Conflicts:
      neutron/plugins/ml2/drivers/openvswitch/agent/openflow/ovs_ofctl/br_int.py
      (no 'dump_flows_for' method so dump_flows had to be used with an additional
       check of the in_port on existing rules)

    Closes-Bug: #1558658
    Change-Id: I02984b21872e0f183db7404c10d8180dbd89075f
    (cherry picked from commit 997d7b03fb7f5528f0a3ce70867b9dcd9321509e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299023
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=cc275e4975450947fa9d9e55ef42475a25bf611d
Submitter: Jenkins
Branch: stable/mitaka

commit cc275e4975450947fa9d9e55ef42475a25bf611d
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 02:45:11 2016 -0700

    Linux Bridge: Add mac spoofing filtering to ebtables

    The current mac-spoofing code in iptables has two issues.
    First, it occurs after the address discovery allow rules
    (e.g. DHCP), so MAC addresses can be spoofed on discovery
    protocols. Second, since it is based on iptables, it
    doesn't apply to protocols like STP.

    This means a VM could generate one of these types of packets
    with a spoofed MAC address to trick switches into learning
    that the spoofed MAC now belongs to the VM's port. The impact
    of this depends on the configuration of the environment
    (e.g. use of L2pop: see the bug report for details).

    This patch adds MAC spoofing filtering to the ARP protection
    code for Linux bridge based on ebtables. Only traffic sourced
    from the MAC address on the port or in the allowed address
    pair MACs will be allowed.

    This filtering will not be enabled if the port has port
    security disabled or if the device_owner starts with 'network:'.

    Change-Id: I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78
    Partial-Bug: #1558658
    (cherry picked from commit be298f8bc35e6d006c7a9361e42755c9d6790e1e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299024
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d7dc90946407d27eec9063f05f33e3f4888ad395
Submitter: Jenkins
Branch: stable/mitaka

commit d7dc90946407d27eec9063f05f33e3f4888ad395
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 04:47:28 2016 -0700

    OVS: Add mac spoofing filtering to flows

    The mac-spoofing filtering done by iptables was
    not adequate. See the bug report and change
    I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78 for
    more information.

    This patch adds flows to the OVS agent to block
    any traffic from the VM that isn't in the allowed
    address pairs macs or the mac address field of
    the port.

    Closes-Bug: #1558658
    Change-Id: I02984b21872e0f183db7404c10d8180dbd89075f
    (cherry picked from commit 997d7b03fb7f5528f0a3ce70867b9dcd9321509e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299027
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d626eb24a304a0ba53311aa1bb877f60c974da72
Submitter: Jenkins
Branch: stable/kilo

commit d626eb24a304a0ba53311aa1bb877f60c974da72
Author: Kevin Benton <email address hidden>
Date: Fri Mar 25 02:45:11 2016 -0700

    Linux Bridge: Add mac spoofing filtering to ebtables

    The current mac-spoofing code in iptables has two issues.
    First, it occurs after the address discovery allow rules
    (e.g. DHCP), so MAC addresses can be spoofed on discovery
    protocols. Second, since it is based on iptables, it
    doesn't apply to protocols like STP.

    This means a VM could generate one of these types of packets
    with a spoofed MAC address to trick switches into learning
    that the spoofed MAC now belongs to the VM's port. The impact
    of this depends on the configuration of the environment
    (e.g. use of L2pop: see the bug report for details).

    This patch adds MAC spoofing filtering to the ARP protection
    code for Linux bridge based on ebtables. Only traffic sourced
    from the MAC address on the port or in the allowed address
    pair MACs will be allowed.

    This filtering will not be enabled if the port has port
    security disabled or if the device_owner starts with 'network:'.

    Conflicts:
     neutron/plugins/linuxbridge/agent/arp_protect.py
     neutron/tests/functional/agent/linux/test_linuxbridge_arp_protect.py
        (simple conflicts on both due to utils.is_trusted_port logic being gone)

    Change-Id: I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78
    Partial-Bug: #1558658
    (cherry picked from commit be298f8bc35e6d006c7a9361e42755c9d6790e1e)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299028
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d48147b0fc192c49646951294479573e4ed9ae78
Submitter: Jenkins
Branch: stable/kilo

commit d48147b0fc192c49646951294479573e4ed9ae78
Author: Kevin Benton <email address hidden>
Date: Mon Mar 28 22:21:53 2016 -0700

    OVS: Add mac spoofing filtering to flows

    The mac-spoofing filtering done by iptables was
    not adequate. See the bug report and change
    I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78 for
    more information.

    This patch adds flows to the OVS agent to block
    any traffic from the VM that isn't in the allowed
    address pairs macs or the mac address field of
    the port.

    Conflicts:
        This had to be heavily modified to work with Kilo due to
        the lack of a pluggable openflow interface that was present
        in master, mitaka, and liberty.

    Closes-Bug: #1558658
    Change-Id: I02984b21872e0f183db7404c10d8180dbd89075f
    (cherry-picked from 997d7b03fb7f5528f0a3ce70867b9dcd9321509e)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 2015.1.4 release.

[OpenStack Infra (hudson-openstack)]

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

[Tristan Cacqueray (tristan-cacqueray)]

Dustin, is change 315828 ( Ia1f9d768004871d743d2c7b979de1439667efe52 ) a security fix or does it fix a regression caused by one of the fix part of this upcoming advisory ? ftr, the current list of patch for the ossa are:

* Ice1c9dd349864da28806c5053e38ef86f43b7771 (icmpv6)
* Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5 (dhcp)
* I39dc0e23fc118ede19ef2d986b29fc5a8e48ff78 (arp)

[Tristan Cacqueray (tristan-cacqueray)]

Here is the final impact description:

Title: Neutron anti-spoof protection bypass
Reporter: Romain Aviolat (Nagravision) and Dustin Lundquist (Blue Box Group, Inc)
Products: Neutron
Affects: <=7.0.4, >=8.0.0 <=8.1.0

Description:
Romain Aviolat from Nagravision and Dustin Lundquist from Blue Box
Group, Inc independently reported vulnerabilities in Neutron anti-
spoof protection. By forging DHCP discovery messages or non-IP
traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source
addresses on attached networks resulting in denial of services and/or
traffic interception. Moreover when L2population isn't used, other
tenants attached to a shared network are also vulnerable. Neutron
setups using the IPTables firewall driver are affected.

[Dustin Lundquist (dlundquist)]

Tristan, change 315828 addresses the OVS Firewall which currently has many of these same problems. Specifically table 71 (BASE_EGRESS_TABLE) permits specific ICMPv6 types, DHCP and DHCPv6 before validating source MAC or IP addresses. This allows IPv6 spoofing: neighbor discovery is permitted without any address validation. In addition the DHCP (IPv4) could be used to mask the source address of flood attack or release the DHCP lease of another instance (potentially belonging to another tenant on a shared network). In addition all the of above traffic types could be used to cause an physical switch to learn an incorrect port of another instance or router's MAC address potentially intercepting another tenants traffic on a shared provider network.

I finally have a working OVS Firewall test environment and this is my initial analysis of the OpenFlow rules it produces. I think all of the above vulnerabilities are addressed in the existing bug reports. I know the OVS Firewall is recent addition, so I'm not sure how it falls into the security advisory process.

[Tristan Cacqueray (tristan-cacqueray)]

Hum, well that's the problem with catch-all advisory where similar issues can be found later.
I propose we change impact description title to "Neutron IPTables firewall anti-spoof protection bypass" and move with it.

For the OVS Firewall case, I've added an ossa task to track this issue separately. If you agree, please review the new title and impact description posted in comment #52 so that we can request a CVE and proceed with the advisory.

[OpenStack Infra (hudson-openstack)]

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

commit a323769143001d67fd1b3b4ba294e59accd09e0e
Author: Ryan Moats <email address hidden>
Date: Tue Oct 20 15:51:37 2015 +0000

    Revert "Improve performance of ensure_namespace"

    This reverts commit 81823e86328e62850a89aef9f0b609bfc0a6dacd.

    Unneeded optimization: this commit only improves execution
    time on the order of milliseconds, which is less than 1% of
    the total router update execution time at the network node.

    This also

    Closes-bug: #1574881

    Change-Id: Icbcdf4725ba7d2e743bb6761c9799ae436bd953b

commit 7fcf0253246832300f13b0aa4cea397215700572
Author: OpenStack Proposal Bot <email address hidden>
Date: Thu Apr 21 07:05:16 2016 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: I9e930750dde85a9beb0b6f85eeea8a0962d3e020

commit 643b4431606421b09d05eb0ccde130adbf88df64
Author: OpenStack Proposal Bot <email address hidden>
Date: Tue Apr 19 06:52:48 2016 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: I52d7460b3265b5460b9089e1cc58624640dc7230

commit 1ffea42ccdc14b7a6162c1895bd8f2aae48d5dae
Author: OpenStack Proposal Bot <email address hidden>
Date: Mon Apr 18 15:03:30 2016 +0000

    Updated from global requirements

    Change-Id: Icb27945b3f222af1d9ab2b62bf2169d82b6ae26c

commit b970ed5bdac60c0fa227f2fddaa9b842ba4f51a7
Author: Kevin Benton <email address hidden>
Date: Fri Apr 8 17:52:14 2016 -0700

    Clear DVR MAC on last agent deletion from host

    Once all agents are deleted from a host, the DVR MAC generated
    for that host should be deleted as well to prevent a buildup of
    pointless flows generated in the OVS agent for hosts that don't
    exist.

    Closes-Bug: #1568206
    Change-Id: I51e736aa0431980a595ecf810f148ca62d990d20
    (cherry picked from commit 92527c2de2afaf4862fddc101143e4d02858924d)

commit eee9e58ed258a48c69effef121f55fdaa5b68bd6
Author: Mike Bayer <email address hidden>
Date: Tue Feb 9 13:10:57 2016 -0500

    Add an option for WSGI pool size

    Neutron currently hardcodes the number of
    greenlets used to process requests in a process to 1000.
    As detailed in
    http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html

    this can cause requests to wait within one process
    for available database connection while other processes
    remain available.

    By adding a wsgi_default_pool_size option functionally
    identical to that of Nova, we can lower the number of
    greenlets per process to be more in line with a typical
    max database connection pool size.

    DocImpact: a previously unused configuration value
               wsgi_default_pool_size is now used to a...

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 8.1.1 release.

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 7.1.0 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 9.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/301977
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=756540a726aa7309fcd7916c5f22ede66badeb1e
Submitter: Jenkins
Branch: master

commit 756540a726aa7309fcd7916c5f22ede66badeb1e
Author: Tristan Cacqueray <email address hidden>
Date: Tue Apr 5 19:41:31 2016 -0400

    Adds OSSA 2016-009 (CVE-2016-5362, CVE-2016-5363 and CVE-2015-8914)

    Change-Id: Iad029108209fc631da286c777e8485106cea7f53
    Related-Bug: #1502933
    Related-Bug: #1558658

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/315828
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 2015.1.4 release.