| 2020-11-04 17:13:22 |
David Sinquin |
bug |
|
|
added bug |
| 2020-11-04 17:13:22 |
David Sinquin |
attachment added |
|
anti-spoof.patch https://bugs.launchpad.net/bugs/1902917/+attachment/5431130/+files/anti-spoof.patch |
|
| 2020-11-04 17:30:05 |
Jeremy Stanley |
description |
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
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. This
embargo shall not extend past $NINETY_DAYS and will be made
public by or on that date even if no fix is identified.
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
|
| 2020-11-04 17:30:24 |
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. This
embargo shall not extend past $NINETY_DAYS and will be made
public by or on that date even if no fix is identified.
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
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. This
embargo shall not extend past 2021-02-02 and will be made
public by or on that date even if no fix is identified.
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
|
| 2020-11-04 17:30:44 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2020-11-04 17:30:57 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2020-11-04 17:31:10 |
Jeremy Stanley |
bug |
|
|
added subscriber Neutron Core Security reviewers |
| 2020-11-05 18:16:29 |
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. This
embargo shall not extend past 2021-02-02 and will be made
public by or on that date even if no fix is identified.
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
Using Open vSwitch on an ussuri setup with neutron 16.0.0, VMs can send ICMPv6 Neighbor Advertisement packets with no check on their content to mis-direct traffic to them.
This looks a lot like https://bugs.launchpad.net/neutron/+bug/1502933 except it affects Open vSwitch driver rather than iptables.
Pre-condition:
- two running VMs in the same L2 flat network with IPv6 connectivity
How to reproduce:
- manually add a custom IPv6 on one (e.g. `ip -6 address add fe80::42/64 dev eth0`)
- ping it from the other, expecting no answer (e.g. `ping -c1 -w1 "fe80::42%eth0"`)
- confirm it updated its neighbor table (e.g. `ip -6 neigh get fe80::42/64 dev eth0`)
Expected behavior:
- VMs should not be able to advertise IPv6 addresses that are not assigned to them e.g. through neighbor advertisement packets.
Affected versions:
The Openstack version I am using is Ussuri with neutron 16.0.0, with minor changes on commit df5b28c2e5. From a quick review of the diff with master, I think the issue is also present there. Network part is using Open vSwitch on flat network with Xen 4.13 as hypervisor.
Similarly, UDP packets using DHCP query ports (for DHCP v4 or v6) can be sent with arbitrary IP and MAC addresses.
And I think we are fine for other ICMP types (redirect, router renumbering for ICMPv6) as I did not managed to have such packets sent between VMs but I fail to understand how it gets filtered.
I am attaching a couple patches that I think fix the issues but include no tests and include changes that we may want to avoid (in case plugins out of neutron git repo use firewall.ICMPV6_ALLOWED_EGRESS_TYPES). |
|
| 2020-11-05 18:16:40 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
| 2020-11-05 18:20:40 |
Jeremy Stanley |
cve linked |
|
2015-8914 |
|
| 2020-11-10 14:41:15 |
Rodolfo Alonso |
neutron: importance |
Undecided |
High |
|
| 2020-11-11 09:36:46 |
Dr. Jens Harbott |
bug |
|
|
added subscriber Dr. Jens Harbott |
| 2021-02-09 06:20:32 |
Summer Long |
bug |
|
|
added subscriber Summer Long |
| 2021-02-16 21:43:02 |
Slawek Kaplonski |
neutron: assignee |
|
Slawek Kaplonski (slaweq) |
|
| 2021-02-19 10:44:38 |
Slawek Kaplonski |
neutron: status |
New |
In Progress |
|
| 2021-02-27 20:11:05 |
Slawek Kaplonski |
neutron: status |
In Progress |
Fix Released |
|
| 2021-03-05 01:40:14 |
Summer Long |
cve linked |
|
2021-20267 |
|
| 2021-03-05 15:35:51 |
Jeremy Stanley |
ossa: status |
Incomplete |
In Progress |
|
| 2021-03-05 15:35:59 |
Jeremy Stanley |
ossa: importance |
Undecided |
High |
|
| 2021-03-05 15:36:05 |
Jeremy Stanley |
ossa: assignee |
|
Jeremy Stanley (fungi) |
|
| 2021-03-05 15:36:19 |
Jeremy Stanley |
summary |
Anti-spoofing bypass using Open vSwitch |
Anti-spoofing bypass using Open vSwitch (CVE-2021-20267) |
|
| 2021-03-19 13:35:18 |
Slawek Kaplonski |
neutron: status |
Fix Released |
In Progress |
|
| 2021-05-10 12:15:14 |
Antoine Eiche |
bug |
|
|
added subscriber Antoine Eiche |
| 2021-05-14 13:57:38 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Released |
|
| 2021-05-31 19:36:52 |
OpenStack Infra |
tags |
|
in-stable-train |
|
| 2021-06-01 13:48:48 |
OpenStack Infra |
tags |
in-stable-train |
in-stable-train in-stable-ussuri |
|
| 2021-06-04 09:30:55 |
OpenStack Infra |
tags |
in-stable-train in-stable-ussuri |
in-stable-rocky in-stable-train in-stable-ussuri |
|
| 2021-06-04 09:31:04 |
OpenStack Infra |
tags |
in-stable-rocky in-stable-train in-stable-ussuri |
in-stable-queens in-stable-rocky in-stable-train in-stable-ussuri |
|
| 2021-06-04 10:20:35 |
OpenStack Infra |
tags |
in-stable-queens in-stable-rocky in-stable-train in-stable-ussuri |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri |
|
| 2021-06-04 20:51:11 |
OpenStack Infra |
tags |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria |
|
| 2021-06-06 06:46:16 |
OpenStack Infra |
tags |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria in-stable-wallaby |
|
| 2021-06-11 08:29:36 |
Bernard Cafarelli |
tags |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria in-stable-wallaby |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria in-stable-wallaby neutron-proactive-backport-potential |
|
| 2021-06-11 08:44:02 |
Bernard Cafarelli |
tags |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria in-stable-wallaby neutron-proactive-backport-potential |
in-stable-queens in-stable-rocky in-stable-stein in-stable-train in-stable-ussuri in-stable-victoria in-stable-wallaby |
|
| 2021-07-12 17:41:15 |
OpenStack Infra |
ossa: status |
In Progress |
Fix Released |
|
| 2021-08-02 16:56:01 |
Jeremy Stanley |
summary |
Anti-spoofing bypass using Open vSwitch (CVE-2021-20267) |
[OSSA-2021-001] Anti-spoofing bypass for Open vSwitch networks (CVE-2021-20267) |
|
