← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1558658] Re: Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests

 

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 <kevin@xxxxxxxxxx>
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


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1558658

Title:
  Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP
  requests

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Triaged

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1558658/+subscriptions