Update (9/7/22): This vulnerability is now being used in a new malware called Shikitega. This malware is downloaded in multiple parts to ultimately gain access to the system.

Somewhere in the early days of computing, it was decided that a minimum of two classes of privileges were required on a system – a normal user and an operator or administrator. Ever since, there has been a never-ending cat-and-mouse game of elevating a user to operator or administrative access. It should be no surprise then, that recent CVEs such as CVE-2021-4034, colloquially called POLKIT, provide yet another tool in attacker’s toolbox for achieving root-level access (operator or administrator level privileges).

One thing that we continue to stress is that an attacker will always get root-level access on a system (read more here). Given that an attacker will always get root and POLKIT provides just another way to do accomplish that, how do we protect our systems?

POLKIT Vulnerability

But first, let’s take a quick peak at the POLKIT vulnerability. Not because it’s novel, but because it’s a run of the mill memory corruption / out of bounds error that can be used to elevate privileges, and maybe even more because it has existed for more than 12 years.

POLKIT has been shown to be only a local privilege escalation vulnerability (meaning an attacker must already have execution context on the system), but that doesn’t mean an enterprising attacker couldn’t find a way to make it a remote privilege escalation vulnerability by chaining various flaws and/or misconfigurations together in a complex flow. The actual POLKIT vulnerability results in the relative positioning of the argument and environment arrays in memory of the POLKIT application. At the end of the day, an attacker can force POLKIT, a SETUID (meaning it effectively runs as root) program to execute an arbitrary program as root. The flaw itself is a combination of assumptions and lack of proper validation of potentially user-controlled data, combined with where and how these arrays are traditionally stored in memory.

Shortly after POLKIT we even postulated internally that no SETUID program is safe, when even applications such as beep have had privilege escalation vulnerabilities in them.

How Cyber Hardening Suite Can Help

Alright, cool we now have a fancy new way to get root-level access on a system, but how do we defend against it?

Repeat after me, there is no Silver Bullet to Security.

We fundamentally need to change how we design, implement, and deploy our systems. We need to consider security from the beginning as it will drive how we update systems, how systems are used, and how we integrate with the back-end systems. As we continually see, whether it’s by finding vulnerabilities in the 10 Properties of Secure Embedded Systems or using CVEs such as POLKIT, attackers will always find a way to get root. As for most attack scenarios and end games, root-level access is required for persistence and/or accessing sensitive data. One way to start designing systems with security in mind is to use existing functionality within a Linux environment (a quick introduction on it can be found here).

This is the approach that Star Lab’s Kevlar Embedded Security takes – we leverage and integrate existing security functionality within a Linux environment, while also assuming an attacker will get root-level access. Using a capability such as Star Lab’s Kevlar Embedded Security, where it is assumed, an attacker will get root-level access, introduces various design constraints and impacts the way system functions such as updates are handled. This product and its underlying assumptions require that it be introduced early in the development process, such that updates and system performance can be adequately addressed. While it’s possible to retrofit a capability such as Star Lab’s Kevlar Embedded Security into an existing system, the underlying design assumption that an attacker will get root-level access may necessitate additional design considerations in order to permit devices to be updated in the field.

What Can You Do Immediately?

What can you do to secure your system besides using solutions like Star Lab’s Kevlar Embedded Security? What can you do right now?

As a point solution, the best thing you can do now is update your systems, since most vendors have already released patches to address POLKIT. However, updating the systems, only addresses a single vulnerability, and attackers keep finding new ways to get root-level access. Patches are only a stop gap until a new technique is discovered, which will kick off another round of updates and patching.

Fundamentally, we need to switch our mindset around security, to realize an attacker will always strive to get administrative-level privileges and we can’t keep them out. We can, however, limit the scope of what an attacker can do once they get administrative access while we work towards having defense in depth instead of relying on point solutions. With that in mind, here are some things to mitigate an attacker getting root-level access:

Attack Surface Reduction – Remove unused packages, modules, and kernel features. Similarly, limit and/or remove setuid binaries / applications.

Implement mandatory access control policies on the system using SELinux (or another MAC LSM). The SELinux policies can be made static and built into the kernel to make it harder for an attacker to change, modify or disable.
Reduce system calls used by an application, especially those started by systemd, to help containerize and confine applications.

Containerize applications – Separate and isolate existing applications to only the libraries that are needed. This could include the use of containers, virtual machines, and possibly other Linux features such as namespaces.
Implement an integrity verification system for all files on the system. This will help detect modifications that might have been made to establish persistence, execute a launcher, or inhibit correct system functionality.

Establish and utilize defense in depth. As silly as it sounds, no single technique or tool can fully prevent vulnerabilities such as POLKIT from being found and used. However, we can take steps to mitigate the damage that can be caused when they are identified. Defense in depth for this situation includes attack surface reduction, enforcing some form of secure boot, enforcing mandatory access controls, routine system updates, implementing some form of allowlisting, and even auditing of the system.

In order to take advantage of local privilege escalation vulnerabilities such as POLKIT, an attacker needs to already have (unpriviledged) execution. We can ask ourselves, how would an attacker gain such execution and do we have protections in place to help prevent that execution in the first place?

Do we permit users and backend processes to ssh into the system, thereby providing direct execution? If that’s the case, maybe we can limit where that remote access can be performed through firewall rules and implement a specialized restricted shell for those remote operations.
Do we have something that allows command injection, such as a web interface with various parameter escape vulnerabilities. If that’s the case, we can look at various static / dynamic code analysis tools to help prevent the introduction of the vulnerability, as well as implement MAC polices with SELinux and limit system calls to our applications.

Is the execution a result of return-oriented-programming (ROP)? There are various techniques in the kernel and userspace, some of which may require your applications to be recompiled, which can be used to help mitigate ROP.

Ultimately, the POLKIT vulnerability sets the stage for a greater discussion on securing systems and the complexity of that effort. It is one of countless similar vulnerabilities that can be fixed one by one, or be thwarted by an overarching security posture that mitigates the end goal of the attacker using it.

Many of the steps or protections that can be implemented now to help address vulnerabilities such as POLKIT can also be found in our 7 Tenet of Layered Security in Embedded Systems whitepaper.

For more information on how Star Lab’s Kevlar Embedded Security can secure your embedded systems to help mitigate the potential impacts of vulnerabilities like POLKIT, reach out to us.

To dive deeper on security topics, download one of our whitepapers below!