On Sept. 14, CVE-2020-14386 was reported as a “high” severity threat. This CVE is a kernel security vulnerability that enables an unprivileged local process to gain root access to the system. CVE-2020-14386 is a result of a bug found in the packet socket facility in the Linux kernel. It allows a bad actor to trigger a memory corruption that can be exploited to hijack data and resources, and in the most severe case, completely take over the system. The biggest threat from this vulnerability is to data confidentiality and integrity. Kernel versions newer than 4.6 on various Linux distributions are affected by this bug, including:
- Ubuntu Bionic (18.04) and newer
- Debian 9
- Debian 10
- CentOS 8/RHEL 8
Mitigating CVE-2020-14386
There are a few things you can do to mitigate the effects of CVE-2020-14386:- Patch your operating system: The most immediate action to take is to schedule a maintenance window to patch a vulnerable host.
- Disable
CAP_NET_RAW: Scheduling a maintenance window always takes time that leaves the environment exposed. A quick step you should consider is disablingCAP_NET_RAWby default. In most Red Hat systems this is already disabled. - Kubernetes PodSecurityPolicies: Configure Pod Security Policy to drop the
CAP_NET_RAWcapability in running containers, as suggested here by Google.
Detecting CVE-2020-14386 with Falco
The root cause of the CVE-2020-14386 vulnerability is an incorrect offset calculation in the functiontpacket_recv used by packet sockets. This means that a user-controlled input can cause an out of bound write, allowing an attacker to potentially take control of the system.
To exploit the vulnerability, the CAP_NET_RAW capability needs to be enabled in the attacker’s namespace. Since raw sockets allow for certain classes of network attacks, any use of them in a system should be a red flag.
While the first step anyone should take is scanning for OS vulnerabilities, there is still a need for implementing runtime threat detection to cover for those vulnerabilities that aren’t public yet or don’t have an available fix.
Falco, the open-source cloud-native runtime security project, detects unexpected application behavior and alerts on threats at runtime. By tapping into Sysdig open source libraries through Linux system calls, it can run in high-performance production environments. Falco also ingests Kubernetes API audit events to provide runtime detection and alerting for orchestration activity. By adding Kubernetes application context, teams can understand exactly who did what.
One of the advantages of Falco is the active community that is constantly improving the out-of-the-box rules and and building a library with real-life use cases they encounter.
This vulnerability is a great example of how a Falco rule a user contributed in 2019 can be used to detect any attempt to open a packet socket in the system.
rule: Packet socket created in container desc: Detect new packet socket at the device driver (OSI Layer 2) level in a container. Packet socket could be used to do ARP Spoofing by attacker. condition: evt.type=socket and evt.arg[0]=AF_PACKET and consider_packet_socket_communication and container and not proc.name in (user_known_packet_socket_binaries) output: Packet socket was created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline socket_info=%evt.args container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag) priority: NOTICE tags: [network, mitre_discovery]The output would be something like:
18:22:38.501982124: Notice Packet socket was created in a container (user=root command=CVE-2020-14386 socket_info=domain=17(AF_PACKET) type=3 proto=768 container_id=72a39d9aa408 container_name=gallant_buck image=cve-2020-14386_container:latest)An incident like this highlights the powerful ability of the Falco engine to detect malicious activity inside containers
Detecting CVE-2020-14386 with Sysdig Secure
The Falco engine is embedded in Sysdig Secure to allow easy identification of suspicious behavior at the system level. Below, you can see how the rule from earlier looks like in the Sysdig Secure UI. You can save time identifying threats with defining precise conditions, and apply automatic remediation actions such as kill, stop, or pause containers that violate this rule.
Identify vulnerable OS versions with Sysdig Secure
The most straightforward way to identify a vulnerable system is to collect the OS versions used across the environment to flag any potentially vulnerable system. When using Sysdig Secure, the rich data collected from every node in the systems also include the underline OS version. This can be used to easily identify vulnerable hosts, including which workloads are currently running on the host, to associate risk, prioritize patching of the system, and to quickly locate the environment and owner of the host.
Setting Pod Security Policies using the Sysdig PSP Advisor
If you are using Kubernetes, a powerful mechanism you can leverage is Pod Security Policies. With Pod Security Policies, you can drop capabilities in your running environment, preventing anyone from exploiting this vulnerability. The challenge in real-life production environments is the ability to evaluate the impact of applying a global configuration, for example, identifying which workloads are going to be affected. While security is important, the business impact of taking a production system down is always something you need to consider. For example, although it is uncommon for a Pod to needCAP_NET_RAW, you shouldn’t just block this capability completely. Some pods that work directly with the network, like Istio, do need it.
Sysdig Secure PSP Advisor allows simulating a PodSecurityPolicy that drops CAP_NET_RAW. Simulating a policy allows real-time visibility into the workloads that are going to be impacted, and gives an operator the ability to tune a rule according to their runtime environment constraints, making sure nothing breaks.
