Etienne Champetier

**Name of the Vulnerable Software and Affected Versions** No specific software or versions are mentioned in the provided descriptions. **Description** The issue is related to the implementation of the Ethernet encapsulation protocol, specifically concerning the combination of headers. This could allow a remote attacker to cause a denial of service or implement a man-in-the-middle (MITM) attack. Layer 2 network filtering capabilities, such as IPv6 RA guard or ARP inspection, can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Windows Hyper-V (affected versions not specified) **Description** The issue is related to errors in security settings of the Windows Hyper-V service, which can be exploited by a remote attacker to cause a denial of service by sending specially crafted data. This allows attackers to affect the system. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Docker Engine versions prior to 19.03.11 **Description** The issue is related to a lack of input validation in the CAP NET RAW component of Docker Engine, which can be exploited by a remote attacker to gain access to sensitive information, compromise data integrity, and cause a denial of service. An attacker with the CAP NET RAW capability in a container can craft IPv6 router advertisements to spoof external IPv6 hosts. **Recommendations** For Docker Engine versions prior to 19.03.11, update to version 19.03.11 or later to resolve the issue. As a temporary workaround, consider restricting the use of the CAP NET RAW capability in containers to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** CNI versions 0.7.4 and earlier Kubernetes versions prior to 1.11.9 Kubernetes versions prior to 1.12.7 Kubernetes versions prior to 1.13.5 Kubernetes versions prior to 1.14.0 **Description** The issue is related to a network firewall misconfiguration in the CNI 'portmap' plugin. This plugin is used to set up HostPorts for CNI and inserts rules at the front of the iptables nat chains, which take precedence over the KUBE-SERVICES chain. As a result, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. **Recommendations** For CNI version 0.7.4, update to version 0.7.5 to resolve the issue. For Kubernetes versions prior to 1.11.9, update to version 1.11.9 or later. For Kubernetes versions prior to 1.12.7, update to version 1.12.7 or later. For Kubernetes versions prior to 1.13.5, update to version 1.13.5 or later. For Kubernetes versions prior to 1.14.0, update to version 1.14.0 or later.

**Name of the Vulnerable Software and Affected Versions** runc versions prior to 1.0.0-rc95 **Description** The issue allows a container filesystem breakout via directory traversal. To exploit this, an attacker must be able to create multiple containers with a fairly specific mount configuration. The problem occurs via a symlink-exchange attack that relies on a race condition, specifically a time-of-check-to-time-of-use (TOCTTOU) flaw. This can be exploited by creating a symlink in a volume to a top-level directory where volumes are sourced from, and then using that symlink as the target of a mount. The source of the mount is an attacker-controlled directory, allowing the attacker to bind-mount the host filesystem into the container. While recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces can restrict the damage, they do not block this attack outright. **Recommendations** For versions prior to 1.0.0-rc95, update to version 1.0.0-rc95 or later to fix the issue. As a temporary workaround, consider restricting access to the vulnerable `runc` functionality until a patch is applied, and enforce running containers with more confined security profiles, such as reduced capabilities, not running code as root in the container, user namespaces, AppArmor/SELinux, and seccomp.