Given this bug report is over 4 years old and has been entirely inactive
for more than 3, it seems unlikely to rise to the level of urgency where
we'd issue an OSSA even if it did eventually get fixed. As such, I'm
closing the Security Advisory task as Won't Fix, but if there are any
dissenting opinions I'm happy to reopen and revisit that decision.
** 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/1884341
Title:
Anti-spoofing bypass
Status in neutron:
New
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Hello OpenStack Team,
Looking at the neutron code I believe OpenStack to be vulnerable to VLAN0
stacking when using iptables + ebtables (bridge only, not OVS).
I was not able to validate this issue on an OpenStack deployment (I tried to
setup microstack but was unable to connect to the VMs ...)
VLAN 0 or priority tagging allow to add 802.1p class of service information
to a packet.
When received by a linux machine (I haven't checked Windows or other OS
behavior) the VLAN header with VID=0 is removed and the packet processed as if
there was no VLAN header (It actually loop until there is no VLAN 0 headers
left).
Now Linux bridge firewall (net.bridge.bridge-nf-call-*tables) handles the
packets normally, ie a packet with a VLAN header will not match any ip*tables
rules on the forward path, which is expected.
When enabling net.bridge.bridge-nf-filter-vlan-tagged=1, it will go look into
the first VLAN header, but not deeper.
Using this simple scapy script:
```
ra = Ether()/Dot1Q(vlan=0)/Dot1Q(vlan=0)
ra /= IPv6(dst='ff02::1')
ra /= ICMPv6ND_RA(chlim=64, prf='High', routerlifetime=1800)
ra /= ICMPv6NDOptSrcLLAddr(lladdr=get_if_hwaddr('enp1s0'))
ra /= ICMPv6NDOptPrefixInfo(prefix="2001:db8:1::", prefixlen=64,
validlifetime=1810, preferredlifetime=1800)
sendp(ra)
```
We send an IPv6 router advertisement stacked on top of 2 VLAN 0 headers
This bypass any ip6tables rules, and looking at the usage of ebtables in
neutron it should go thru as it's not ARP (I only see ebtables used in
arp_protect.py and matching ARP protocol)
When received by a neighboor Linux VMs it's accepted.
This same attack should allow DHCP, ARP or any traffic spoofing.
(We might be able to use NFQUEUE to had VLAN 0 headers to all our egress
packets to bypass MAC/IP checks)
I've seen some system actually use VLAN 0 tagged packets by default
(Cisco UCS) so a possible fix is to allow 1 level of VLAN 0 and enable
net.bridge.bridge-nf-filter-vlan-tagged=1
In my tests Linux 'removes' both Dot1Q(vlan=0) and Dot1AD(vlan=0).
(for example this is accepted by Linux:
'Ether()/Dot1Q(vlan=0)/Dot1Q(vlan=0)/Dot1AD(vlan=0)/Dot1Q(vlan=0)')
I wasn't able to find any reference to VLAN 0 attacks searching on
Google, so this might affect other OSS projects (I need to check LXC
at least, maybe some K8S CNI)
All my tests were performed with a Fedora 32 host (Linux 5.6) running
2 ubuntu 20.04 VM, and using scapy 2.4.3.
Best
Etienne Champetier
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1884341/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
