{"uuid": "e3183518-6039-45bb-bf00-2da4c6341113", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-14386", "type": "seen", "source": "https://t.me/cissp/1398", "content": "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker):\n\ud83d\udc4d\ud83c\udffd\u270c\ud83c\udffc\ud83d\ude00\nAn interesting vulnerability affecting the Linux kernel was disclosed earlier this month, CVE-2020-14386. Essentially, a memory corruption issue in net/packet/af_packet.c that can be exploited to overwrite up to 10 bytes of memory and potentially gain root privileges from unprivileged processes.\nThe full disclosure post is at https://www.openwall.com/lists/oss-security/2020/09/03/3\nThe primary requirement for potential exploitation for this is that the target system needs to have the CAP_NET_RAW capability enabled.\u00a0\nWhen we look at this issue from a Kubernetes or general container point of view, the issue could allow an attacker within a container to escape and access the underlying node. Imagine a scenario where an attacker has gained access to a pod by exploiting a vulnerability in a service that is exposed. A web application with SQL Injection perhaps? Or a file upload feature that can be abused? In any case, an attacker-in-a-pod is a very real threat owing to how web applications are written and services can potentially be configured.\nAn attacker would be able to abuse the extended capabilities to generate a spoofed packet with incorrect values within the packet and cause an out of bounds write of user controlled data. This can be used to execute user controlled code to possibly escape the container and obtain root privileges on the host node. This is rated as a High severity vulnerability.\nIf you are on GKE, Google has issued a security bulletin, GCP-2020-012, describing the mitigations that need to be applied - https://cloud.google.com/kubernetes-engine/docs/security-bulletins#gcp-2020-012\nTo detect if your cluster is vulnerable, you can enumerate privileges within the pods using capsh, pscap or getcap from the libcap2-bin, libcap-ng-utils or libcap-progs packages respectively. The command would be run using kubectl or via a shell within the pod. For example -\nkubectl exec podname --capsh --print\nIf we look closely at the Threat Matrix for Kubernetes - , the Execution tactic aligns with how an attacker would be able to reach and gain execution within a pod. Prevalence of vulnerabilities like CVE-2020-14386 allow for an attacker within a pod to attempt lateral privilege escalation to escape out of the container (Privilege escalation tactic). Once an attacker has gained access to a node, based on the RBAC and namespaces configured, the attacker would be able to list K8S secrets, access application credentials in configuration files, identify additional nodes to attack, gain access to and abuse internal networking, hijack resources to perform cryptomining (popular lately) or perform denial of service attacks.\nIssues like these make the container world exciting for attackers as post exploitation scenarios vary drastically then when attacking say an individual standalone box.", "creation_timestamp": "2026-09-02T01:05:02.980971Z"}