yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

this bug should be fixed openly as a strengthening measure.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1302080

Title:
  Host is accessible from instance using Linux bridge IPv6 address

Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Security Advisories:
  Won't Fix

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
         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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1302080/+subscriptions