Blog Icon

Blog Post

Detecting CVE-2020-14386 with Falco and mitigating potential container escapes

NEW!! LIVE WEBINAR: NIST 800-53 Compliance in Containers & Kubernetes - Nov 5, 2020 10am Pacific / 1pm Eastern

On September 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:

  1. Patch your operating system: The most immediate action to take is to schedule a maintenance window to patch a vulnerable host.
  2. Disable CAP_NET_RAW: Scheduling a maintenance window always takes time that leaves the environment exposed. A quick step you should consider is disabling CAP_NET_RAW by default. In most Red Hat systems this is already disabled.
  3. Kubernetes PodSecurityPolicies: Configure Pod Security Policy to Drop the CAP_NET_RAW capability in running containers, as suggested here by Google.

The shared nature of containerized environments and Kubernetes makes the vulnerability even more critical due to the possibility to elevate process permissions and trigger a container escape. CVE-2019-5736: runc container breakout is one example of a “high” severity CVE that was similar in nature. This vulnerability led to root privilege by overwriting the underlying library, creating a large blast radius that requires everyone to patch.

Detecting CVE-2020-14386 with Falco

The root cause of the CVE-2020-14386 vulnerability is an incorrect offset calculation in the function tpacket_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 need CAP_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.

Conclusion

Allowing someone to gain direct access to the kernel and to the hardware resources inside the host, is like leaving your door unlocked and going on vacation. As organizations continue to move more mission-critical applications to the containers and Kubernetes, bad actors will refocus more time on finding and exploiting vulnerabilities in containers.

CVE-2020-14386 is a good reminder that while containers and Kubernetes provide better isolation and security, runtime detection (via tools like Falco/Sysdig Secure) and least privilege access control (via Sysdig PSP Advisor) must be enforced.

Some related links

Stay up to date

Sign up to receive our newest.

Related Posts

Detect CVE-2020-8555 using Falco

Detect CVE-2020-8557 using Falco

How to detect CVE-2019-14287 using Falco