On a Fedora 35 workstation installation (up to date as of 14 Dec 21), I have libvirt/qemu/kvm (all fedora repo default; the virtual network is provided by
libvirt) installed to use it as hypervisor. Additional to the dependencies, I also installed
libvirt-daemon-config-nwfilter.x86_64, which is active (only the default filters!):
virsh # nwfilter-list
The test environment within my qemu/kvm/libvirt contains in its virtual network (all in one subnet of course; as it is configured by default): one client** vm that connects
nc <ip server> 8080, one server** vm that offers
nc -l 8080, one attacker vm that aims to take over the MAC & IP of the server. All is Fedora 35, just like the host (but the client/server vm’s are Fedora Server, not workstation), up to date as of 14 Dec 21. I used just the standard tools to do all of this:
ifconfig (including the attacker vm; no penetration tools or such).
libvirt-daemon-config-nwfilter on the hypervisor, MAC and IP takeover is still very easy: the attacker machine can change the MAC to the targeted machine, then deactivate+activate network interface, and the default DHCP of the hypervisor does the rest: IP of the target gets assigned to the attacker; no warning and no indication at any level.
When this has happened, requests are forwarded to the machine that was active last (simple
ICMP is sufficient for that; thus, its easy to keep the attacker dominant for the majority of requests).
This is a minor issue on workstations, but in corporate or cloud environments (relevant mostly for the upstream distributions) this could be exploitable if one machine from the given network was taken over (and far too many machines are often combined in a virtual network instead of separating the subnets where it is possible or reasonable). Many SMBs have less sophisticated administration capabilities (which may include SMB cloud providers). About two years ago, I asked around informally at events etc. about who was aware of the issue when setting up
libvirt networks (also including occupational admins). Most did not know anything about it (of course this informal survey was not representative).
I was trying to find an easy to implement solution, but I could not find one. In fact, I couldn’t get rid of the exploitation possibility within one virtual net at all. In a mail to the libvirt team about two years ago, I was told that it is possible to solve this with
nwfilter (I had no success with it; I also tested it with a simple HTTP server, not just nc, and all with Fedora and CentOS). The default filters
no-arp-spoofing (see nwfilter-list output above) I installed automatically with
libvirt-daemon-config-nwfilter.x86_64 made no difference (at least not by default config). Currently, I do not see a difference in defining further filters (feel free to challenge this assumption) …
Any ideas how to solve or mitigate the issue?
If so, it could be thought of making such a solution to the default configuration since most materials potential admins use to config their systems do not make aware of such issues (although this is more serious in the upstream distributions). Theoretically, an adjustment of the default config could include to make
libvirt-daemon-config-nwfilter.x86_64 a dependency of
libvirt-daemon-driver-nwfilter.x86_64 as it increases security, even if that specific issue remains (I don’t see any negative impact of this). I am a big fan of not shifting such issues to the assumption that any admin of such environments will know about it
Just to avoid the discussion: don’t forget that at this level, DNS-dependent solutions cannot mitigate that issue. Currently, the only mitigations I see are
- asymmetric crypto means, or the increased use of subnets (which can be cumbersome and/or annoying for (or simply unknown to) many admins and cause them not to implement it; especially in complex and fast-changing corporate/cloud environments in today’s organizational architectures; but also for normal users of VM technologies).
- adjusting the management of the ARP table (how to mitigate here without creating noticeable effects?)
Ideas of how to do the latter? Alternatives?
I know that I merge a bit a discussion thread and an ask thread, but as the technical issue (that indeed contains open questions) is the foundation of any related discussion, I thought it makes sense to keep it together, and to start here. Especially as ask.fedora is more active in terms of technical issue handling. The question for a problem solution is the focus for now.
- Client vm: no open ports (Fedora Server Default)
- Server vm: 8080/tcp 8080/udp (Fedora Server default +
- Hypervisor is Fedora Workstation default, but this is unrelated to the issue.
Looking forward to your ideas!