libvirt_lxc resolves a host name after the guest filesystem is mounted but before the init from it is executed. That in turn causes glibc to load libnss_dns.so and it ends up being loaded from the guest tree, making it possible for the guest to inject executable code before the host filesystem is umounted and file handles closed. That has potential security implications.
Created libvirt tracking bugs for this issue: Affects: fedora-all [bug 1542815] Created mingw-libvirt tracking bugs for this issue: Affects: fedora-all [bug 1542814]
Upsptream fix is in git as: commit 759b4d1b0fe5f4d84d98b99153dfa7ac289dd167 Author: Lubomir Rintel <lkundrak> Date: Sat Jan 27 23:43:58 2018 +0100 virlog: determine the hostname on startup CVE-2018-6764 At later point it might not be possible or even safe to use getaddrinfo(). It can in turn result in a load of NSS module. Notably, on a LXC container startup we may find ourselves with the guest filesystem already having replaced the host one. Loading a NSS module from the guest tree would allow a malicous guest to escape the confinement of its container environment because libvirt will not yet have locked it down.
libvirt-3.7.0-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Patch: https://libvirt.org/git/?p=libvirt.git;a=commit;h=759b4d1b0fe5f4d84d98b99153dfa7ac289dd167 https://libvirt.org/git/?p=libvirt.git;a=commit;h=6ce3acc129bfdbe7fd02bcb8bbe8af6d13903684 https://libvirt.org/git/?p=libvirt.git;a=commit;h=c2dc6698c88fb591639e542c8ecb0076c54f3dfb
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:3113 https://access.redhat.com/errata/RHSA-2018:3113