| 2016-03-17 16:24:49 |
Dustin Lundquist |
bug |
|
|
added bug |
| 2016-03-17 16:32:12 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2016-03-17 16:32:19 |
Tristan Cacqueray |
ossa: status |
New |
Incomplete |
|
| 2016-03-17 16:33:21 |
Tristan Cacqueray |
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. |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
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. |
|
| 2016-03-17 16:33:43 |
Tristan Cacqueray |
bug |
|
|
added subscriber Neutron Core Security reviewers |
| 2016-03-25 12:17:55 |
Kevin Benton |
attachment added |
|
bug_1558658.patch https://bugs.launchpad.net/neutron/+bug/1558658/+attachment/4611129/+files/bug_1558658.patch |
|
| 2016-03-29 22:57:42 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
| 2016-03-29 22:57:59 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
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. |
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. |
|
| 2016-03-29 23:05:39 |
OpenStack Infra |
neutron: status |
New |
In Progress |
|
| 2016-03-29 23:05:39 |
OpenStack Infra |
neutron: assignee |
|
Kevin Benton (kevinbenton) |
|
| 2016-03-31 20:30:40 |
OpenStack Infra |
neutron: assignee |
Kevin Benton (kevinbenton) |
Dustin Lundquist (dlundquist) |
|
| 2016-04-05 18:33:43 |
OpenStack Infra |
neutron: assignee |
Dustin Lundquist (dlundquist) |
Kevin Benton (kevinbenton) |
|
| 2016-04-05 18:44:34 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Triaged |
|
| 2016-04-06 12:11:41 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Released |
|
| 2016-04-14 18:10:48 |
OpenStack Infra |
tags |
|
in-stable-mitaka |
|
| 2016-04-14 18:11:26 |
OpenStack Infra |
tags |
in-stable-mitaka |
in-stable-liberty in-stable-mitaka |
|
| 2016-04-14 18:11:45 |
OpenStack Infra |
tags |
in-stable-liberty in-stable-mitaka |
in-stable-kilo in-stable-liberty in-stable-mitaka |
|
| 2016-04-20 06:29:26 |
Kevin Benton |
neutron: importance |
Undecided |
High |
|
| 2016-05-09 11:44:00 |
Dave Walker |
nominated for series |
|
neutron/kilo |
|
| 2016-05-09 11:44:01 |
Dave Walker |
bug task added |
|
neutron/kilo |
|
| 2016-05-10 01:03:49 |
OpenStack Infra |
neutron/kilo: status |
New |
In Progress |
|
| 2016-05-10 01:03:49 |
OpenStack Infra |
neutron/kilo: assignee |
|
Kevin Benton (kevinbenton) |
|
| 2016-05-10 07:25:40 |
OpenStack Infra |
neutron/kilo: status |
In Progress |
Fix Committed |
|
| 2016-05-10 22:04:09 |
Dave Walker |
neutron/kilo: milestone |
|
2015.1.4 |
|
| 2016-05-10 22:05:54 |
Dave Walker |
neutron/kilo: status |
Fix Committed |
Fix Released |
|
| 2016-05-27 16:30:31 |
Ihar Hrachyshka |
tags |
in-stable-kilo in-stable-liberty in-stable-mitaka |
in-stable-kilo in-stable-liberty in-stable-mitaka neutron-proactive-backport-potential |
|
| 2016-06-10 15:07:33 |
Tristan Cacqueray |
ossa: status |
Triaged |
In Progress |
|
| 2016-06-13 07:41:42 |
Tristan Cacqueray |
summary |
Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests |
Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363) |
|
| 2016-06-13 07:41:53 |
Tristan Cacqueray |
cve linked |
|
2016-5362 |
|
| 2016-06-13 07:42:04 |
Tristan Cacqueray |
cve linked |
|
2016-5363 |
|
| 2016-06-14 06:49:26 |
OpenStack Infra |
cve linked |
|
2015-8914 |
|
| 2016-06-14 06:54:30 |
Tristan Cacqueray |
summary |
Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363) |
[OSSA-2016-009] Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363) |
|
| 2016-06-14 06:56:08 |
Tristan Cacqueray |
ossa: status |
In Progress |
Fix Released |
|
| 2016-06-14 07:29:45 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2016-10-07 15:46:25 |
Ihar Hrachyshka |
tags |
in-stable-kilo in-stable-liberty in-stable-mitaka neutron-proactive-backport-potential |
in-stable-kilo in-stable-liberty in-stable-mitaka |
|
| 2018-07-23 20:34:10 |
Slavik Anikeyev |
ossa: assignee |
|
Vyacheslav Anikeyev (slavik1991) |
|
| 2018-07-24 11:30:09 |
Jeremy Stanley |
ossa: assignee |
Vyacheslav Anikeyev (slavik1991) |
|
|
