Host is accessible from instance using Linux bridge IPv6 address
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Brian Haley | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
Medium
|
Brian Haley |
Bug Description
Opening this as a security bug just in case - but I doubt it is.
If a compute node has enabled auto configuration for IPv6 addresses on all interfaces, then the Linux bridges used for connecting instances will get IPv6 addresses too. Then an instance can reach the host using the address of the bridge it is connected to.
Eg with the ovs-agent and hybrid VIF driver after booting an instance in devstack connected to the "private" network:
vagrant@devstack:~$ brctl show
bridge name bridge id STP enabled interfaces
br-ex 0000.9619b7f0614b no qg-97601dc1-77
br-int 0000.cad7ebe11e46 no qr-edf68f52-f9
qbre8eabd6a-46 8000.0e8e27c7cdfa no qvbe8eabd6a-46
vagrant@devstack:~$ ip address show dev qbre8eabd6a-46
15: qbre8eabd6a-46: <BROADCAST,
link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff
inet6 fe80::dcc6:
valid_lft forever preferred_lft forever
Note: the address fe80::dcc6:
$ ssh ubuntu@172.24.4.3
ubuntu@vm1:~$ ip address show dev eth0
2: eth0: <BROADCAST,
link/ether fa:16:3e:d1:7e:fe brd ff:ff:ff:ff:ff:ff
inet 10.0.0.9/24 brd 10.0.0.255 scope global eth0
inet6 fe80::f816:
valid_lft forever preferred_lft forever
ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::f816:
64 bytes from fe80::f816:
64 bytes from fe80::dcc6:
64 bytes from fe80::f816:
64 bytes from fe80::dcc6:
64 bytes from fe80::f816:
64 bytes from fe80::dcc6:
64 bytes from fe80::f816:
ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:
PING fe80::dcc6:
64 bytes from fe80::dcc6:
ubuntu@vm1:~$ ssh fe80::dcc6:
The authenticity of host 'fe80::
ECDSA key fingerprint is 11:5d:55:
Are you sure you want to continue connecting (yes/no)?
I thought the anti-spoof rules should block packets from the fe80 address, but looking at the ip6tables-save (attached) the spoof chain and its default DROP rule are missing. That must be because there is no IPv6 subnet on the "private" network - maybe that's another problem. I inserted them manually, but that did not work becuase these packets hit the host's INPUT chain and the security group filters are on the FORWARD chain.
So maybe all that is needed is a note in the doc to say that auto config should be disabled by default and selectively enabled on interfaces if needed. E.g.:
net.ipv6.
net.ipv6.
net.ipv6.
# enable on lo and eth1
net.ipv6.
net.ipv6.
Or maybe the VIF drivers should disable IPv6 on the bridge when creating it.
description: | updated |
description: | updated |
Changed in ossa: | |
status: | New → Incomplete |
Changed in neutron: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in neutron: | |
assignee: | nobody → Aniruddha Singh Gautam (aniruddha-gautam) |
tags: | added: ipv6 |
tags: | added: network |
Changed in nova: | |
status: | New → In Progress |
assignee: | nobody → Adam Kacmarsky (adam-kacmarsky) |
importance: | Undecided → Medium |
assignee: | Adam Kacmarsky (adam-kacmarsky) → Brian Haley (brian-haley) |
Changed in nova: | |
assignee: | Brian Haley (brian-haley) → Rawlin Peters (rawlin-peters) |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
assignee: | Rawlin Peters (rawlin-peters) → Brian Haley (brian-haley) |
What releases of Neutron are affected by this bug?
Neutron core security reviewers, any opinion on the scope and exploitability of this?