On Fri, Jul 14, 2023 at 12:12 AM ROOT@HardenedVault <root@hardenedvault.net> wrote:

https://hardenedvault.net/blog/2023-07-09-protecting-linux-kernel-why-how/

July 9, 2023 | 14 min Read

+PROTECTING LINUX AT KERNEL LEVEL WHY AND HOW

Introduction

We designed Vault Exploits Defense (VED) as a foundation security layer for various flavors of Linux operating system.

The kernel-level protection has long been the most challenging technology in the cyber space. HardenedVault has pioneered an innovative way of realizing total protection at runtime. Its product, **Vault Exploits Defense (VED), detects and blocks both known (Nday) and unknown (0day) Linux kernel exploits that are often extremely lethal yet extremely evasive.

In recent testing, VED protects against 96% of published exploits against Linux without any security patch. The conclusion was using public statistics of Ubuntu security tracker, MITRE, and public PoC/Exploits.

Problems

Typical exploits against the OS kernels are memory corruption, process credential stealing, etc. Since most of these exploits are happening inside and even below the OS kernel, they are evasive from plain sights and hard to track. Furthermore, kernel exploits are often extremely lethal since they are already at the deepest layers and having highest operation privileges.

While security has always been a critical cornerstone in the modern operating system’s kernel, vulnerabilities persist. Worse, since kernel level exploits tend to be much more potent and lethal, as such exploits have already managed to bypass intrinsic layers of security measures.

The picture below is such an example. A bug in the Linux heap gives away the entire system to the adversary, without being ever discovered, until 15 years later in 2021.

Evidently, current kernel security mechanisms in place will not detect, let along defend against such attacks. Although providing great protection, they are policy-driven based on knowledge of known bad behaviors. To protect against those and future unknown threats, a new security mechanism is necessary.

Solution

The Concept

Since most of the kernel level exploits require a carefully cultivated code path to leverage a string of vulnerabilities in a particular yet abnormal order, it is possible to analyze and fingerprint such code paths. Similar patterns also exist in the areas of authorization and memory access. Taking an analogy of finding a genetic sequence of a pathogen, we call it “the kernel vaccination”.

Additionally, VED has also instrumented post-detection operations to allow automated, policy-driven response to threats. For example, VED can put a system into a total lockdown state if an unauthorized privilege escalation is detected; another example, installing VED onto an already-exploited system will block any existing rootkits planted before VED.

VED has been proven to defeat many pre-existing exploits without any specific modifications or policies. Thus, it will likely defeat many future exploits (including of yet unknown vulnerabilities). While any security measures are bypass-able, bypassing VED requires more sophisticated analysis on ever changing VED code base, resulting in less reliable and persistent exploits..

VED also provides security through polymorphism by using diversified flavors of Linux distributions, resulting in subtle changes in code paths, yet still enjoying the benefits of a unified Linux experience.

How VED works

VED is a runtime protection solution for the Linux kernel, designed to defend against 0day/Nday vulnerabilities and detect post-exploitation attacks. VED has developed defense mechanisms against exploitation methods, including:

Specific Code Path Detection (wCFI): wCFI enforces the detection of functions commonly used by attackers to build ROP chains. Once an ROP attack is detected, it will be blocked.
Integrity Checking: Attackers often overwrite important data structures to achieve privilege escalation. VED performs integrity checking on these data structures and blocks and alerts if any modifications are detected.
Self-Protection Capability: Self-protection is critical for security products because if compromised, the entire system may be at risk. Overall, VED is designed to block attack methods (exploitation methods) rather than individual vulnerabilities.
Post-exploitation threat detection and blocking. For example, if VED is running on a compromised host, it may detect and block rootkits that are hidden within the system.

The Benefit

Currently, VED can block over 96% of the known exploits. Because the VED technologies are not CVE-specific, it can be deduced that VED shall have a close blocking ratio on unknown exploits.

There are small cases of vulnerabilities that VED can’t not detect, which currently account for <4% of CVEs. Yet with post-exploit protection, the effective damages can be even smaller.

The Use Cases

Use Case 1: Cloud Native Container Hosts Breach

Environment: 100% security compliance environment with HIDS, EDR, XDR, SIEM and SOC.
Incident: Server compromised by ransomware
Solution: VED provides runtime protection

Use Case 2: Linux Server, ETHEREUM VALIDATOR NODES

Environment: Blockchain servers, Linux Servers, Ethereum in Cold Wallet but validation key in Linux servers
Operation: Private key storage for Ethereum validator nodes
Solution: VED offers both runtime and post-attack protection by blocking already implanted rootkit from booting.

Use Case 3: Industrial 4.0: Edge computing gateway (ARM64) security protection

Environment: Edge IoT gateway running Linux connected to PLC and RFID
Incident: N/A Solution: VED provides runtime protection work with additional security solution including Mandatory Access Control, Seccomp-based sandboxing, firewall policies, etc.

The Deployment

VED is a kernel module (not a kernel patch) supporting almost all variations of Linux kernels on most of the distributions. There are three major modes of deployment that shall be tailored to a wide range of customers.

On-premises Repository

For customers who need to certify their own distributions, we help them build a repository server where VED can be built, certified, and installed.

Cloud-native Instance

We also offer cloud-native Linux images from various distributions with Hardened Linux so they are a turn-key solution for anyone wanting a highly secured Linux virtual server.

Direct DKMS Distribution (via ved.sh)

For customers who like the simplicity and ease of management, HardenedVault also offers a cloud repository service so VED can be directly downloaded and installed. Compatible with Ansible.

Check if VED work?

ubuntu@raspi-test:~ $ sudo dmesg |grep VED

[ 3.712272] VED: ALIVE: Loading VED...

[ 4.223929] VED: ISSUE: [kretprobe] register_kretprobe() for <ovl_dentry_is_whiteout> failed! [err=-2]

[ 4.223967] VED: ISSUE: Can't hook 'ovl_dentry_is_whiteout'. This is expected when OverlayFS is not used.

[ 4.995028] VED: ALIVE: VED initialized successfully

ubuntu@raspi-test:~ $

ubuntu@raspi-test:~ $ sudo lsmod |grep -i ved

ved 167936 0

Offering

The current version of VED is the corporate version in beta stage. The kernel module is already stable, but there is a lack of management UI as all operations are prompted through command line or API calls, so it is mainly targeted for customers with in-house Linux admin.

VED is actively maintained and constantly updated to address any new missing threats or fixing bugs. We support almost all flavors of Linux distributions and with corresponding deployment mechanisms. The quality of code has been proven by many users around the world.

Applicable Markets

VED shall be used in a wide range of application environments, particularly for those requiring high levels of security and protection from targeted attacks.

Direct industries markets

Industries such as finance, healthcare, or government may need to protect sensitive information from unauthorized access may be targeted by advanced attackers who use sophisticated attack techniques to breach their systems. In these cases, additional security enhancements like VED is a part of an essential layer of protection against these threats.

Critical infrastructure systems or servers

Systems such as web servers or database servers, may also benefit from additional kernel security enhancements. These systems are often targeted by attackers seeking to disrupt operations or steal sensitive data and may require additional security measures beyond what is provided by the base Linux kernel.

Unattended Systems

IoT systems, especially systems operating in open fields and even in hostile network and physical environments, require higher security strength to defend against foreign elements.

Wallet, Staking Nodes, Validating Nodes

A wallet based on a general computing platform, as well as the keys for off-chain nodes and validation nodes, are all important assets. Attackers usually craft targeted attack chains, from information gathering and vulnerability exploitation to persistence via rootkits and lateral movement, in order to obtain these assets. VED not only provides runtime protection but also detects and blocks rootkit backdoors on compromised systems.

Finally, users who value security and privacy in general may choose to use additional kernel security enhancements as a way to improve the overall security of their systems and protect their personal data from unauthorized access.

Conclusion

In summary, the VED is an essential layer of kernel security on top of the generalized security instruments from vendors or open sources. It's important to understand that the existing security framework can only address known security issue with a huge lag, often beyond 12 months for kernel space exploits, not to mention most of the kernel exploits are so valuable thus will never be revealed to the professional security communities.

About Us

HardenedVault develops and deploys full-stack open source infrastructure security from hardware, firmware, Linux kernel and secure communication protocol. We provide the building blocks for the customer to build their own “Cyber Bunker” by utilizing 0day/Nday exploit defense techniques, trusted/confidential computing with next-gen firmware security and cryptography.

From the boot process of each node (machine), the root-of-trust anchored in multiple hardware components, then the chains of trust extending from firmware, operating systems to application. The crucial parts of each component follow compliance/regulation while are still able to defend against the known and unknown vulnerability and exploit vectors by integrating the modern mitigation and access control. In addition, the communication between each node must guarantee confidentiality and integrity but it’s not enough from advanced threat protection’s perspective.

HardenedVault also provides the off-chain secure communication protocol with zero-knowledge proof to enable metadata protection (to protect machine’s privacy) and deniability by default. This is the cornerstone and foundation to help the user to build their own decentralized data center/cloud.

Update about new exploit vectors

Eliminating one or two exploit vectors (methods of exploiting vulnerabilities) is more valuable than hard-coded defenses against a pile of 0-day exploits. Any known or unknown (n-day/0-day) vulnerability can be reforged by exploit writers that’d be making it difficult for defense systems to keep up. Therefore, an unknown exploit vector is more threatening than a pile of 0-day vulnerabilities. VED has evolved over the years to possess specific features that fall between the pre-exploitation and exploitation stages. It not only has immunity to exploit vectors such as the one bypassed Tetragon or Pipe primitives but can also detect and prevent typical exploitation methods at an earlier stage.

Try Hardened Ubuntu on AWS (integrated with VED-LTS)

Appendix 1: Competitive Analysis

Compare VED with GRSecurity or any other kernel security solution.

Feature	SELinux	Apparmor	GRSecurity / PaX	LKRG	AKO	VED
MAC (Mandatory Access Control)	YES	YES	YES	NO	NO	NO
Audit	YES	YES	YES	Auxiliary logging	Auxiliary logging	Auxiliary logging
Work with LSM	YES	YES	YES	YES	YES	YES
Reduce the infoleak	NO	NO	YES	NO	NO	Partial
Arbitrary code execution prevention	NO	NO	YES	YES	NO	YES
Userspace access prevention	NO	NO	YES	YES	NO	YES
Refcount overflow prevention	NO	NO	YES	NO	NO	NO
Read-only for important func pointer and data structure	NO	NO	YES	YES	Partial support	YES
Self-protection	NO	NO	YES	NO	NO	YES
Important metadata integrity	NO	NO	NO	NO	NO	YES
Post-exploitation reaction	NO	NO	NO	YES	NO	YES
Process integrity protection	NO	NO	N/A	NO	NO	YES
Lockdown mode (APT containment)	NO	NO	N/A	NO	NO	YES

Appendix 2: CVE Reference Testing

In our testing on vulnerable distro kernels, VED successfully detected certain pre-existing exploits:

Case Number	NIST Description	Vulnerability life-cycle
CVE-2014-9322	arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not properly handle faults associated with the Stack Segment (SS) segment register, which allows local users to gain privileges by triggering an IRET instruction that leads to access to a GS Base address from the wrong space.	Nov 2009 – Dec 2014
CVE-2017-5123	Insufficient data validation in waitid allowed a user to escape sandboxes on Linux, missing “access_ok” return check.	Apr 2005 – Oct 2017
CVE-2017-6074	The dccp_rcv_state_process function in net/dccp/input.c in the Linux kernel through 4.9.11 mishandles DCCP_PKT_REQUEST packet data structures in the LISTEN state, which allows local users to obtain root privileges or cause a denial of service (double free) via an application that makes an IPV6_RECVPKTINFO setsockopt system call.	Sep 2006 – Feb 2017
CVE-2021-22555	A heap out-of-bounds write affecting Linux since v2.6.19-rc1 was discovered in net/netfilter/x_tables.c. This allows an attacker to gain privileges or cause a DoS (via heap memory corruption) through user name space	Sep 2006 – Apr 2021
CVE-2021-3573	A use-after-free in function hci_sock_bound_ioctl() of the Linux kernel HCI subsystem was found in the way user calls ioct HCIUNBLOCKADDR or other way triggers race condition of the call hci_unregister_dev() together with one of the calls hci_sock_blacklist_add(), hci_sock_blacklist_del(), hci_get_conn_info(), hci_get_auth_info(). A privileged local user could use this flaw to crash the system or escalate their privileges on the system. This flaw affects the Linux kernel versions prior to 5.13-rc5.	Feb 2012 – May 2021
CVE-2021-33909	fs/seq_file.c in the Linux kernel 3.16 through 5.13.x before 5.13.4 does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root by an unprivileged user	Jul 2014 – Jul 2021
CVE- 2021-34866	This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel 5.14-rc3. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of eBPF programs. The issue results from the lack of proper validation of user-supplied eBPF programs, which can result in a type confusion condition. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel. Was ZDI-CAN-14689.	Jun 2020 – Aug 2021
CVE-2021-43267	An issue was discovered in net/tipc/crypto.c in the Linux kernel before 5.14.16. The Transparent Inter-Process Communication (TIPC) functionality allows remote attackers to exploit insufficient validation of user-supplied sizes for the MSG_CRYPTO message type.	Oct 2016 – Feb 2022
CVE-2021-42008	The decode_data function in drivers/net/hamradio/6pack.c in the Linux kernel before 5.13.13 has a slab out-of-bounds write. Input from a process that has the CAP_NET_ADMIN capability can lead to root access.	Apr 2005 – Aug 2021
CVE-2022-0185	A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling) could use this flaw to escalate their privileges on the system.	Feb 2019 – Jan 2022
CVE-2022-0492	A vulnerability was found in the Linux kernel’s cgroup_release_agent_write in the kernel/cgroup/cgroup-v1.c function. This flaw, under certain circumstances, allows the use of the cgroups v1 release_agent feature to escalate privileges and bypass the namespace isolation unexpectedly.	Dec 2016 – Jan 2022
CVE-2022-25636	net/netfilter/nf_dup_netdev.c in the Linux kernel 5.4 through 5.6.10 allows local users to gain privileges because of a heap out-of-bounds write. This is related to nf_tables_offload.	Sep 2019 – Feb 2022
CVE-2022-1015	A flaw was found in the Linux kernel in linux/net/netfilter/nf_tables_api.c of the netfilter subsystem. This flaw allows a local user to cause an out-of-bounds write issue.	Oct 2013 – Mar 2022
CVE-2022-1016	A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle ‘return’ with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker.	Jan 2021 – Mar 2022

Additional tests on samples of undisclosed 0day vulnerabilities also shows successful detection and blocking.

On the false negative/false positive side, VED has one false-negative case, whereas it could not detect the following exploit:

Case Number	NIST Description
CVE-2016-5195	Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by leveraging incorrect handling of a copy-on-write (COW) feature to write to a read-only memory mapping, as exploited in the wild in October 2016, aka “Dirty COW”

This is because they directly target the userspace even if via the kernel. While in case of Dirty COW the VED "bypass" happened due to the nature of the bug and this being the way to exploit it, it's also a way for future exploits to bypass VED by similarly directly targeting userspace.

So far, there is no false-positive case yet.