ARMOs’ customers immune – by design – against vulnerabilities like CVE-2020-14386

CVE-2020-14386 is yet another severe vulnerability that was recently discovered in the Linux kernel. It reminds us that the fight against vulnerabilities is not over. This particular one allows a regular application to escalate its privileges and gain root access to the machine. Indeed, it sounds scary. Applications with root privileges can break out of the container, launch “invisible” malicious software or kill/isolate security measures deployed on the machine – and, most dangerous of all, steal or corrupt your data. The world would definitely be a better place without it.

‍
Exploiting the vulnerability

‍We’re lucky that this vulnerability can be exploited only if CAP_NET_RAW kernel capability is enabled. However, this is really down to nothing more than dumb luck. A developer could have made the same mistake a few lines of code earlier, where this condition does not apply.

Nevertheless, many security tools and posture validation providers have proudly declared that they could have prevented this exploit because they disable the CAP_NET_RAW by default. Nobody can deny it, this time it’s true. Unless of course the CAP_NET_RAW is required for your solution to run, which is highly probable because it’s required, for example, for the TCPDUMP utility, which is widely used in DevOps.

How do we protect ourselves from these kinds of vulnerabilities without relying on a lucky capability switch?

Preventing an escalation

‍Whoever expects a one-word answer can stop reading here. Vulnerability exploitation is usually a complex multistep process, which may require more than one vulnerability. Let’s look more closely at this newly discovered vulnerability. It requires bringing up a loop back device, opening a socket with several on-default socket options and then sending a specially crafted message to itself. This is not a code that any application would have in it. So why should we be afraid of this vulnerability at all?

The short answer is because hackers can exploit some other vulnerability inside an application and inject their malicious code, which will trigger the privilege escalation via CVE-2020-14386, turning this application into a highly privileged remotely controlled ghost inside your environment. We should also ask ourselves how much better this kind of ghost would have been without the root privileges. It would still be able to access any data or interface accessible by the original application and steal any information from them.

Choosing the right strategy

Focusing our attention and resources on the prevention of a single (e.g., privilege escalation) vulnerability is a losing strategy. Clever attackers may even deliberately publish a certain vulnerability to draw our attention someplace else, while they target a completely different part of our system. I am not suggesting we should ignore known vulnerabilities, however, but there are different ways to address them. In most cases, legitimate applications will not cause any damage running with known vulnerabilities, even if they run as root. It is the potential injection of malicious code – altering these applications –that makes them so dangerous, with and without the root privileges.

The ARMO approach

‍Instead, of hunting specific vulnerabilities, ARMO takes a completely different approach. We provide continuous runtime validation of application software integrity performed in RAM, right where the software runs, ensuring that only authorized and uncompromised software can run inside a customer solution. This method ensures wider and more proactive protection against many types of vulnerabilities, including the privilege escalation. Our approach protects against the actual exploitation of vulnerabilities and the damage they can cause, regardless of them being previously known or zero-day.

On top of this, ARMO continuously verifies the actual application privilege level to identify a potential escalation that may have been perpetrated from the outside; for example, by sending a malicious network packet to it. We also provide DevOps with a remote-control tool that can drop application privilege levels if an application fails to do so on its own.

Immunity by design

‍Protecting applications and microservices from within is a paradigm-shift approach that does not rely on the infrastructure posture. It assumes that the infrastructure can be compromised at any time, and that the application must protect itself anywhere it runs. This approach can protect a broader spectrum of architectures– from legacy VMs to various container management systems such as Docker, Fargate, Nomad and Kubernetes – and from heavy applications to light-weight microservices.

In addition to runtime integrity, ARMO offers identity-based network API access protection and transparent data encryption capabilities. Working together in one product, these features establish an inherent security layer allowing customers to protect all their solutions, regardless of where they run and whether the attacker is external or an insider with the highest privilege level.