Comment 30 for bug 1884341

Hi Slawek

Thanks for all your testing.

I still haven't setup an all in one OpenStack, so not sure exactly how the networking between multiple nodes works ;), but here is my sumup:

There is basically 2 steps:
1) bypass the filtering rules at the output of the VM, once that is done there is no more checks
2) have our VLAN packet switched to the victim, we know that the normal linux bridge let VLAN 0 tagged packet go through, depending on your hardware switch model/configuration it might let the packet go through
(my understanding is that bridge like brq9d2f6d56-79 would have the VMs interfaces + the physical interfaces)

Also some switch will strip the native VLAN, ie you send a packet with VLAN 42 header, it bypass the filtering rules, exits the compute node, the switch strips the header because VLAN 42 is the native VLAN, sends it to another compute node, enjoy

=> I would not rule out attacks on VMs on different compute nodes too fast, if it's the same L2, it can work in some conditions IMO.

For ML2/OVS with iptables_hybrid driver, the filtering is based on ebtables/iptables, so with VLAN0 the filtering is now only based on ebtables, so we have step 1.
For step 2 I never used OVS, so here some interrogations
- does it strip VLAN 0 ? (that would help the attack)
- does it block VLAN tagged packets by default ?
- what does it do with multiple headers ?

If you do more testing, remember that you can put and arbitrary number of VLAN 0 headers, 802.1q or 802.1ad
Ether()/Dot1AD(vlan=0)/Dot1Q(vlan=0)/Dot1AD(vlan=0)/Dot1AD(vlan=0)

The best fix is to only allow arp/ip4/ip6 in ebtables and drop everything else, but that might not be acceptable for OpenStack (that's what LXD is doing now).
Dropping Dot1AD(vlan=0) and Dot1Q(vlan=0) in ebtables might not be enough (see native VLAN stripping by the switch) so I would go to full Dot1AD/Dot1Q drop at least.