| 2015-10-05 15:08:00 |
xens |
bug |
|
|
added bug |
| 2015-10-05 15:17:42 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2015-10-05 15:17:56 |
Jeremy Stanley |
bug |
|
|
added subscriber Neutron Core Security reviewers |
| 2015-10-05 15:18:01 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2015-10-05 15:18:19 |
Jeremy Stanley |
description |
ICMPv6 default firewall rules are too permissive on the hypervisors leaving VMs able to do ICMPv6 source address spoofing.
Pre-condition:
- having a provider-network providing IPv6 connectivity to the VMs
- in my case the controllers are providing statefull DHCPv6 and my physical router provides the default gateway using Router Advertisements.
How to reproduce:
- spin a VM and attach to it an IPv6 enabled network
- obtain an IPv6 address using #dhclient -6
- try to ping6 an IPv6 enabled host
- remove your IPv6 address from the interface: #sudo ip addr del 2001:0DB8::100/32 dev eth0
- add a forged IPv6 address to your interface, into the same subnet of the original IPv6 address: #sudo ip addr add 2001:0DB8::200/32 dev eth0
- try to ping6 the previous IPv6 enabled host, it will still work
- try to assign another IPv6 address to your NIC, completely outside your IPv6 assignment: sudo ip addr add 2001:dead:beef::1/64 dev eth0
- try to ping6 the previous IPv6 enabled host -> the destination will still receive your echo requests with your forget address but you won't receive answers, they won't be router back to you.
Expected behavior:
- VMs should not be able to spoof their IPv6 address and issue forged ICMPv6 packets. The firewall rules on the hypervisor should restrict ICMPv6 egress to the VMs link-local and global-unicast addresses.
Affected versions:
- I saw the issue into OpenStack Juno, under Ubuntu 14.04. But according to the upstream code, the issue is still present into the master branch, into; neutron/agent/linux/iptables_firewall.py, into line 385:
ipv6_rules += [comment_rule('-p icmpv6 -j RETURN', comment=ic.IPV6_ICMP_ALLOW)] |
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.
ICMPv6 default firewall rules are too permissive on the hypervisors leaving VMs able to do ICMPv6 source address spoofing.
Pre-condition:
- having a provider-network providing IPv6 connectivity to the VMs
- in my case the controllers are providing statefull DHCPv6 and my physical router provides the default gateway using Router Advertisements.
How to reproduce:
- spin a VM and attach to it an IPv6 enabled network
- obtain an IPv6 address using #dhclient -6
- try to ping6 an IPv6 enabled host
- remove your IPv6 address from the interface: #sudo ip addr del 2001:0DB8::100/32 dev eth0
- add a forged IPv6 address to your interface, into the same subnet of the original IPv6 address: #sudo ip addr add 2001:0DB8::200/32 dev eth0
- try to ping6 the previous IPv6 enabled host, it will still work
- try to assign another IPv6 address to your NIC, completely outside your IPv6 assignment: sudo ip addr add 2001:dead:beef::1/64 dev eth0
- try to ping6 the previous IPv6 enabled host -> the destination will still receive your echo requests with your forget address but you won't receive answers, they won't be router back to you.
Expected behavior:
- VMs should not be able to spoof their IPv6 address and issue forged ICMPv6 packets. The firewall rules on the hypervisor should restrict ICMPv6 egress to the VMs link-local and global-unicast addresses.
Affected versions:
- I saw the issue into OpenStack Juno, under Ubuntu 14.04. But according to the upstream code, the issue is still present into the master branch, into; neutron/agent/linux/iptables_firewall.py, into line 385:
ipv6_rules += [comment_rule('-p icmpv6 -j RETURN', comment=ic.IPV6_ICMP_ALLOW)] |
|
| 2015-10-07 10:35:56 |
Ihar Hrachyshka |
tags |
|
juno-backport-potential kilo-backport-potential liberty-rc-potential sg-fw |
|
| 2015-10-07 10:36:17 |
Ihar Hrachyshka |
neutron: importance |
Undecided |
High |
|
| 2015-10-07 10:36:29 |
Ihar Hrachyshka |
neutron: milestone |
|
mitaka-1 |
|
| 2015-10-07 10:36:53 |
Ihar Hrachyshka |
neutron: status |
New |
Confirmed |
|
| 2015-10-21 08:19:54 |
Akihiro Motoki |
tags |
juno-backport-potential kilo-backport-potential liberty-rc-potential sg-fw |
juno-backport-potential kilo-backport-potential liberty-backport-potential sg-fw |
|
| 2015-11-09 15:42:07 |
Tristan Cacqueray |
bug |
|
|
added subscriber OSSG CoreSec |
| 2015-11-24 13:02:42 |
Alan Pevec |
tags |
juno-backport-potential kilo-backport-potential liberty-backport-potential sg-fw |
kilo-backport-potential liberty-backport-potential sg-fw |
|
| 2015-12-03 19:18:37 |
Armando Migliaccio |
neutron: milestone |
mitaka-1 |
mitaka-2 |
|
| 2015-12-15 16:28:26 |
Tristan Cacqueray |
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.
ICMPv6 default firewall rules are too permissive on the hypervisors leaving VMs able to do ICMPv6 source address spoofing.
Pre-condition:
- having a provider-network providing IPv6 connectivity to the VMs
- in my case the controllers are providing statefull DHCPv6 and my physical router provides the default gateway using Router Advertisements.
How to reproduce:
- spin a VM and attach to it an IPv6 enabled network
- obtain an IPv6 address using #dhclient -6
- try to ping6 an IPv6 enabled host
- remove your IPv6 address from the interface: #sudo ip addr del 2001:0DB8::100/32 dev eth0
- add a forged IPv6 address to your interface, into the same subnet of the original IPv6 address: #sudo ip addr add 2001:0DB8::200/32 dev eth0
- try to ping6 the previous IPv6 enabled host, it will still work
- try to assign another IPv6 address to your NIC, completely outside your IPv6 assignment: sudo ip addr add 2001:dead:beef::1/64 dev eth0
- try to ping6 the previous IPv6 enabled host -> the destination will still receive your echo requests with your forget address but you won't receive answers, they won't be router back to you.
Expected behavior:
- VMs should not be able to spoof their IPv6 address and issue forged ICMPv6 packets. The firewall rules on the hypervisor should restrict ICMPv6 egress to the VMs link-local and global-unicast addresses.
Affected versions:
- I saw the issue into OpenStack Juno, under Ubuntu 14.04. But according to the upstream code, the issue is still present into the master branch, into; neutron/agent/linux/iptables_firewall.py, into line 385:
ipv6_rules += [comment_rule('-p icmpv6 -j RETURN', comment=ic.IPV6_ICMP_ALLOW)] |
ICMPv6 default firewall rules are too permissive on the hypervisors leaving VMs able to do ICMPv6 source address spoofing.
Pre-condition:
- having a provider-network providing IPv6 connectivity to the VMs
- in my case the controllers are providing statefull DHCPv6 and my physical router provides the default gateway using Router Advertisements.
How to reproduce:
- spin a VM and attach to it an IPv6 enabled network
- obtain an IPv6 address using #dhclient -6
- try to ping6 an IPv6 enabled host
- remove your IPv6 address from the interface: #sudo ip addr del 2001:0DB8::100/32 dev eth0
- add a forged IPv6 address to your interface, into the same subnet of the original IPv6 address: #sudo ip addr add 2001:0DB8::200/32 dev eth0
- try to ping6 the previous IPv6 enabled host, it will still work
- try to assign another IPv6 address to your NIC, completely outside your IPv6 assignment: sudo ip addr add 2001:dead:beef::1/64 dev eth0
- try to ping6 the previous IPv6 enabled host -> the destination will still receive your echo requests with your forget address but you won't receive answers, they won't be router back to you.
Expected behavior:
- VMs should not be able to spoof their IPv6 address and issue forged ICMPv6 packets. The firewall rules on the hypervisor should restrict ICMPv6 egress to the VMs link-local and global-unicast addresses.
Affected versions:
- I saw the issue into OpenStack Juno, under Ubuntu 14.04. But according to the upstream code, the issue is still present into the master branch, into; neutron/agent/linux/iptables_firewall.py, into line 385:
ipv6_rules += [comment_rule('-p icmpv6 -j RETURN', comment=ic.IPV6_ICMP_ALLOW)] |
|
| 2015-12-15 16:28:31 |
Tristan Cacqueray |
information type |
Private Security |
Public Security |
|
| 2016-01-20 18:28:06 |
Armando Migliaccio |
neutron: milestone |
mitaka-2 |
mitaka-3 |
|
| 2016-02-15 16:40:49 |
Mohammed Ashraf |
neutron: assignee |
|
Mohammed Ashraf (mohammed-asharaf) |
|
| 2016-02-17 16:40:46 |
Mohammed Ashraf |
neutron: assignee |
Mohammed Ashraf (mohammed-asharaf) |
|
|
| 2016-03-03 19:57:13 |
Armando Migliaccio |
neutron: milestone |
mitaka-3 |
mitaka-rc1 |
|
| 2016-03-11 19:56:40 |
Armando Migliaccio |
neutron: status |
Confirmed |
Incomplete |
|
| 2016-03-11 19:56:44 |
Armando Migliaccio |
neutron: milestone |
mitaka-rc1 |
|
|
| 2016-03-31 22:26:24 |
OpenStack Infra |
neutron: status |
Incomplete |
In Progress |
|
| 2016-03-31 22:26:24 |
OpenStack Infra |
neutron: assignee |
|
Dustin Lundquist (dlundquist) |
|
| 2016-04-05 18:44:27 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Confirmed |
|
| 2016-05-14 02:33:37 |
OpenStack Infra |
tags |
kilo-backport-potential liberty-backport-potential sg-fw |
in-stable-liberty kilo-backport-potential liberty-backport-potential sg-fw |
|
| 2016-05-14 02:35:40 |
OpenStack Infra |
tags |
in-stable-liberty kilo-backport-potential liberty-backport-potential sg-fw |
in-stable-liberty in-stable-mitaka kilo-backport-potential liberty-backport-potential sg-fw |
|
| 2016-05-16 08:47:31 |
Kevin Benton |
neutron: status |
In Progress |
Fix Committed |
|
| 2016-06-10 15:07:27 |
Tristan Cacqueray |
ossa: status |
Confirmed |
In Progress |
|
| 2016-06-13 07:42:28 |
Tristan Cacqueray |
summary |
ICMPv6 anti-spoofing rules are too permissive |
ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914) |
|
| 2016-06-14 06:49:24 |
OpenStack Infra |
cve linked |
|
2015-8914 |
|
| 2016-06-14 06:49:24 |
OpenStack Infra |
cve linked |
|
2016-5362 |
|
| 2016-06-14 06:49:24 |
OpenStack Infra |
cve linked |
|
2016-5363 |
|
| 2016-06-14 06:54:23 |
Tristan Cacqueray |
summary |
ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914) |
[OSSA-2016-009] ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914) |
|
| 2016-06-14 06:56:02 |
Tristan Cacqueray |
ossa: status |
In Progress |
Fix Released |
|
| 2016-06-14 07:29:26 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2016-06-30 00:37:12 |
Assaf Muller |
tags |
in-stable-liberty in-stable-mitaka kilo-backport-potential liberty-backport-potential sg-fw |
in-stable-liberty in-stable-mitaka sg-fw |
|
| 2022-10-19 15:21:29 |
Rodolfo Alonso |
neutron: status |
Fix Committed |
Fix Released |
|
