Background

In the beginning of the hacker's era, a long-term battle for control of the “CORE” in memory has been waged since Aleph One published the paper Smashing The Stack For Fun And Profit on Phrack Issue 49 in 1996. Attackers mostly targeted user space over the next decade, but as the popularity of userland mitigation became more widespread, more attackers began to shift the “CORE” to the kernel. We've been through the dark age of Linux kernel security when “one null-pointer dereference can pwned them all”. Brad Spengler, one of PaX/Grsecurity authors disclosed the situation of linux kernel security to the public by Washington Post, which led to some reactions from the megacopr of the world: Google, Red Hat, ARM and Intel launched a project called KSPP (Kernel Self-protection project) tends to solve the problem. Unfortunately, KSPP is pretty much collapsed currently due to a serveral reasons, while Linux has moved into more critical infrastructures, such as power, energy, internet of Vehicle, ICS (Industrial Control system), etc. But the issues of Linux kernel security remains unresolved.

The problem is hard to solve

• The chain of fixes for a Linux kernel vulnerability from upstream to Linux distribution kernel (production system) is too long, because the reality is that no one really uses the “upstream” kernel in the sense.

• Stable branch mainters and distribution communities have difficulty following up on the vulnerablity analysis, regression testing, and figuring out defense for each vulnerablity. On the other hand, some security backports might be missed out by either stable branch or distribution kernel.

• The Linux kernel community holds the “security through obscurity” philosophy, which means that they never file a CVE. Even so, there are more than 110 CVE-numbered kernel vulnerabilities between January and August in 2021.

• 0-day business have their own ecosystem, and they don't care if there is a CVE

Our solution: VED (Vault Exploit Defense)

To help the customers solve these problems, HardenedVault developed a Linux kernel 0day protection solution called VED. The threat model basically as follows:

• Work as a LKM (Linux kernel module), the basic implementation framework is hook-based and compatible with the existing security solution's hook system, such as AKO or LKRG.

• Try to block the exploit path at the earlier stage. Otherwise, the detection will try some odds at post-exploitation stage.

• “Watching the watcher” is a philosophical issue in cyber security. VED is an important security product because it's the last line of defense to protect the customer's production system (virtualization, firmware and hardware layer will be present in front of the attacker if the kernel was compromised, so it can be said that VED is the last meaningful line of defense), so VED must have self-protection characteristics.

Some crucial features in VED:

• wCFI, carefully examining important functions at runtime by scanning binary call site in text section for VED && syscalls check the kernel stack (between call and ret) during schedule(). It supports two overlayable defense modes: ** The scope is determined only by whether an instruction before the return address is a call instruction (whether it is an address or register or a pointer). This feature can prevent the arbitrary borrow of code block to build the ROP chain. The only block can be used by ROP is the one between call and ret which is likely bypass wCFI. ** Some functions will be marked by VED: 1) may be favorited by exploit writer 2) Can only be called directly (calling via an address, not a register or pointer). For example, if function B() is the important function being marked and can only be called by function A(), then VED calculates the B()'s address by searching an instruction in A()'s text section like" call *" and compute it with the offset. If VED figures that the A()'s text section doesn't have such instruction, the execution will be blocked.

• Critical data structure protection

• VSPP (VED self-protection project), this is necessary especially when multi threat actors under your threat model:

• Post-exploitation checks on KERNEXEC (SMEP/PXN), UDEREF (SMAP/PAN) , creds, MODHELPER, etc

Situational hardening: Automotive industry

According to UPSTREAM SECURITY'S GLOBAL AUTOMOTIVE CYBERSECURITY REPORT 2020, the attacks from the cloud, infotainment and ECU/TCU/GW are 27.22%, 7.69% and 5.03%:

The proportion of Linux systems running in these systems is very high. Although there are certain requirements for Linux security protection in Requirements on Security Management for Adaptive Platform (AUTOSAR AP R20-11), but it's more like minimal requirements for the vendor. On the other hand, the vehicle is facing more serious situation in the wild:

The technical details has not kept pace with the times, and some amendments/suggestions have been proposed by HardenedVault recently.

Cloud native security architecture

The Kubernetes architecture significantly reduces the difficulty of standardizing development and operations for the business compared to on-premise and virtual machines as the primary business support infrastructure, which is a security benefit and can be reduced to three components based largely on cloud-native security architecture:

• Falco based container security detection system for monitoring and audit. There are two main modes of data collection via Falco's driver (user space-based instrumentation are not discussed here): 1) A tracepoint-based LKM (Linux kernel module) to monitor approximately 88 syscalls can be used by default. 2) An eBPF based implementation can be monitored about 81 syscalls but please noted that this implemenation is based on tracepoints as well. Enterprise users can write and customize code and rules based on the Falco framework to meet their needs.

• To protect kernel components, as the new Falcon deployments increasingly uses eBPF, so it's necessary to protect eBPF as well. The main purpose of kernel protection is prevent the EoP (Esclation of priviledges) and container escape. In such architecture, one successful container escape might leads to the compromised of other Pods/Containers which is matters to data security.

• Hardened ELK or SIEM log server.

In a cloud-native security architecture, VEDs can either work well with Falco or send out logs of blocking attacks to the SIEM/ELK platform for analysis.

Real-life demo

Well, as we received many enquires about a couple of public vulnerablities lately. We demonstrated how VED can defeat a popular one found in kCTF (a Kubernetes-based infrastructure for CTF competitions)