Activity log for bug #1302080

Date Who What changed Old value New value Message
2014-04-03 17:29:14 Darragh O'Reilly bug added bug
2014-04-03 17:29:14 Darragh O'Reilly attachment added ip6tables.out https://bugs.launchpad.net/bugs/1302080/+attachment/4063595/+files/ip6tables.out
2014-04-03 17:57:01 Darragh O'Reilly 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 qvoe8eabd6a-46 tap09437e57-45 qbre8eabd6a-46 8000.0e8e27c7cdfa no qvbe8eabd6a-46 tape8eabd6a-46 vagrant@devstack:~$ ip address show dev qbre8eabd6a-46 15: qbre8eabd6a-46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff inet6 fe80::dcc6:30ff:fe27:37a1/64 scope link valid_lft forever preferred_lft forever Note: the address fe80::dcc6:30ff:fe27:37a1 and login to instance: $ ssh ubuntu@172.24.4.3 ubuntu@vm1:~$ ip address show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 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:3eff:fed1:7efe/64 scope link valid_lft forever preferred_lft forever ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=1 ttl=64 time=16.9 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=38.4 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=2 ttl=64 time=1.44 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=2 ttl=64 time=3.88 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=3 ttl=64 time=8.63 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=3 ttl=64 time=14.0 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=4 ttl=64 time=0.476 ms ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:30ff:fe27:37a1 PING fe80::dcc6:30ff:fe27:37a1(fe80::dcc6:30ff:fe27:37a1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=2.86 ms ubuntu@vm1:~$ ssh fe80::dcc6:30ff:fe27:37a1%eth0 The authenticity of host 'fe80::dcc6:30ff:fe27:37a1%eth0 (fe80::dcc6:30ff:fe27:37a1%eth0)' can't be established. ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5. 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.conf.all.autoconf=0 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 # enable on lo and eth1 net.ipv6.conf.lo.disable_ipv6=0 net.ipv6.conf.eth1.disable_ipv6=0 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        qvoe8eabd6a-46        tap09437e57-45 qbre8eabd6a-46 8000.0e8e27c7cdfa no qvbe8eabd6a-46        tape8eabd6a-46 vagrant@devstack:~$ ip address show dev qbre8eabd6a-46 15: qbre8eabd6a-46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff     inet6 fe80::dcc6:30ff:fe27:37a1/64 scope link        valid_lft forever preferred_lft forever Note: the address fe80::dcc6:30ff:fe27:37a1 and login to instance: $ ssh ubuntu@172.24.4.3 ubuntu@vm1:~$ ip address show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000     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:3eff:fed1:7efe/64 scope link        valid_lft forever preferred_lft forever ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=1 ttl=64 time=16.9 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=38.4 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=2 ttl=64 time=1.44 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=2 ttl=64 time=3.88 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=3 ttl=64 time=8.63 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=3 ttl=64 time=14.0 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=4 ttl=64 time=0.476 ms ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:30ff:fe27:37a1 PING fe80::dcc6:30ff:fe27:37a1(fe80::dcc6:30ff:fe27:37a1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=2.86 ms ubuntu@vm1:~$ ssh fe80::dcc6:30ff:fe27:37a1%eth0 The authenticity of host 'fe80::dcc6:30ff:fe27:37a1%eth0 (fe80::dcc6:30ff:fe27:37a1%eth0)' can't be established. ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5. 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.conf.all.autoconf=0 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 # enable on lo and eth1 net.ipv6.conf.lo.disable_ipv6=0 net.ipv6.conf.eth1.disable_ipv6=0 Or maybe the VIF drivers sould disable IPv6 on the bridge when creating it.
2014-04-03 17:57:24 Darragh O'Reilly 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        qvoe8eabd6a-46        tap09437e57-45 qbre8eabd6a-46 8000.0e8e27c7cdfa no qvbe8eabd6a-46        tape8eabd6a-46 vagrant@devstack:~$ ip address show dev qbre8eabd6a-46 15: qbre8eabd6a-46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff     inet6 fe80::dcc6:30ff:fe27:37a1/64 scope link        valid_lft forever preferred_lft forever Note: the address fe80::dcc6:30ff:fe27:37a1 and login to instance: $ ssh ubuntu@172.24.4.3 ubuntu@vm1:~$ ip address show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000     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:3eff:fed1:7efe/64 scope link        valid_lft forever preferred_lft forever ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=1 ttl=64 time=16.9 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=38.4 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=2 ttl=64 time=1.44 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=2 ttl=64 time=3.88 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=3 ttl=64 time=8.63 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=3 ttl=64 time=14.0 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=4 ttl=64 time=0.476 ms ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:30ff:fe27:37a1 PING fe80::dcc6:30ff:fe27:37a1(fe80::dcc6:30ff:fe27:37a1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=2.86 ms ubuntu@vm1:~$ ssh fe80::dcc6:30ff:fe27:37a1%eth0 The authenticity of host 'fe80::dcc6:30ff:fe27:37a1%eth0 (fe80::dcc6:30ff:fe27:37a1%eth0)' can't be established. ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5. 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.conf.all.autoconf=0 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 # enable on lo and eth1 net.ipv6.conf.lo.disable_ipv6=0 net.ipv6.conf.eth1.disable_ipv6=0 Or maybe the VIF drivers sould disable IPv6 on the bridge when creating it. 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        qvoe8eabd6a-46        tap09437e57-45 qbre8eabd6a-46 8000.0e8e27c7cdfa no qvbe8eabd6a-46        tape8eabd6a-46 vagrant@devstack:~$ ip address show dev qbre8eabd6a-46 15: qbre8eabd6a-46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff     inet6 fe80::dcc6:30ff:fe27:37a1/64 scope link        valid_lft forever preferred_lft forever Note: the address fe80::dcc6:30ff:fe27:37a1 and login to instance: $ ssh ubuntu@172.24.4.3 ubuntu@vm1:~$ ip address show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000     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:3eff:fed1:7efe/64 scope link        valid_lft forever preferred_lft forever ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=1 ttl=64 time=16.9 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=38.4 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=2 ttl=64 time=1.44 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=2 ttl=64 time=3.88 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=3 ttl=64 time=8.63 ms 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=3 ttl=64 time=14.0 ms (DUP!) 64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=4 ttl=64 time=0.476 ms ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:30ff:fe27:37a1 PING fe80::dcc6:30ff:fe27:37a1(fe80::dcc6:30ff:fe27:37a1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes 64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=2.86 ms ubuntu@vm1:~$ ssh fe80::dcc6:30ff:fe27:37a1%eth0 The authenticity of host 'fe80::dcc6:30ff:fe27:37a1%eth0 (fe80::dcc6:30ff:fe27:37a1%eth0)' can't be established. ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5. 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.conf.all.autoconf=0 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 # enable on lo and eth1 net.ipv6.conf.lo.disable_ipv6=0 net.ipv6.conf.eth1.disable_ipv6=0 Or maybe the VIF drivers should disable IPv6 on the bridge when creating it.
2014-04-03 21:20:40 Jeremy Stanley bug added subscriber Neutron Core Security reviewers
2014-04-03 21:21:09 Jeremy Stanley bug task added ossa
2014-04-03 21:21:29 Jeremy Stanley ossa: status New Incomplete
2014-04-22 14:22:36 Thierry Carrez information type Private Security Public
2014-04-22 14:22:41 Thierry Carrez ossa: status Incomplete Won't Fix
2014-07-28 19:23:43 Eugene Nikanorov neutron: importance Undecided Medium
2014-07-28 19:23:55 Eugene Nikanorov neutron: status New Confirmed
2014-11-07 07:32:14 Aniruddha Singh Gautam neutron: assignee Aniruddha Singh Gautam (aniruddha-gautam)
2014-11-23 20:49:33 Eugene Nikanorov tags ipv6
2015-02-17 07:57:27 Dr. Jens Harbott bug added subscriber Dr. Jens Rosenboom
2015-09-16 08:28:22 Ihar Hrachyshka bug task added nova
2015-09-22 19:50:20 Matt Riedemann tags ipv6 ipv6 network
2015-09-22 19:51:27 Matt Riedemann nova: status New In Progress
2015-09-22 19:52:27 Matt Riedemann nova: assignee Adam Kacmarsky (adam-kacmarsky)
2015-09-22 19:53:43 Matt Riedemann nova: importance Undecided Medium
2015-09-22 19:55:14 Matt Riedemann nova: assignee Adam Kacmarsky (adam-kacmarsky) Brian Haley (brian-haley)
2015-10-29 20:57:38 OpenStack Infra nova: assignee Brian Haley (brian-haley) Rawlin Peters (rawlin-peters)
2015-11-03 03:08:40 OpenStack Infra neutron: status Confirmed In Progress
2015-11-03 03:08:40 OpenStack Infra neutron: assignee Aniruddha Singh Gautam (aniruddha-gautam) Brian Haley (brian-haley)
2015-11-18 20:24:17 OpenStack Infra neutron: status In Progress Fix Committed
2015-12-03 21:02:39 Doug Hellmann neutron: status Fix Committed Fix Released
2015-12-09 20:25:01 OpenStack Infra nova: assignee Rawlin Peters (rawlin-peters) Brian Haley (brian-haley)
2016-02-16 06:04:52 OpenStack Infra tags ipv6 network in-stable-liberty ipv6 network
2016-03-30 12:57:58 Brian Haley nova: status In Progress Fix Released
2016-04-18 12:10:28 Tore Anderson bug added subscriber Tore Anderson
2016-05-05 09:35:55 Tore Anderson attachment added network status and neutron-linuxbridge-agent debug output https://bugs.launchpad.net/neutron/+bug/1302080/+attachment/4656256/+files/debug.txt
2016-05-05 16:17:22 Tore Anderson attachment added nova-compute debug log https://bugs.launchpad.net/neutron/+bug/1302080/+attachment/4656541/+files/nova-compute.log
2016-05-06 05:07:03 Tore Anderson attachment removed network status and neutron-linuxbridge-agent debug output https://bugs.launchpad.net/neutron/+bug/1302080/+attachment/4656256/+files/debug.txt
2016-05-06 05:07:23 Tore Anderson attachment removed nova-compute debug log https://bugs.launchpad.net/neutron/+bug/1302080/+attachment/4656541/+files/nova-compute.log
2016-09-12 09:40:09 Kalle Happonen bug added subscriber Kalle Happonen