VED (Vault Exploit Defense): Open source implementation
VED - Linux kernel threat detection and prevention system
LKM version of VED goes public finally.
How VED evolved
Our previous write-up introduced the problem and the current status of Linux kernel security and why cloud native and automotive solution should adopt 3rd-party Linux kernel hardening solution. We’ve been trying to build the full-stack security solution for platform and infrastructure running (GNU)-Linux systems and we learned a lot from PaX/GRsecurity. We continuous study the linux kernel vulnerablity exploit methods disclosured from 2010 to present and see how attacker combined them into the offensive actions, which some cases are public while some are not. Then we began to study how to achieve the trade-off between simplicity of deployment, performance hit, stability and security, which is the starting point of VED’s design and implementation. E.g:
-
To determine whether the detection scope of some code modules should be reduced based on the commonality of the exploit method
-
The VED and Linux kernels are a whole for enterprise production environments, and we also stress-tested the specific versions of Linux kernel subsystems that are highly rely on client’s production through VaultFuzzer to achieve high code coverage.
-
The security solution plays the role of the guardian of the system, and the VED strengthens its protection ability through the VSPP self-protection feature to avoid the weakness of other Linux kernel solution has, e.g: Tetragon, etc.
Theoretically, the features of VED can be compatible with any LKM framework including LKRG, AKO and even a Linux kernel rootkit. Our LKM implementation is finally selected based on open source and long-term maintenance of LKRG. We analyzed the vulnerablity exploitation methods from those public exploits, as well as some 0day vulnerablities provided by the clients.
| Vulnerablity | Mitigation stage |
|---|---|
| CVE-2021-22555 | Exploitation |
| CVE-2021-3573 | Exploitation |
| CVE-2021-3490 | Post-exploitation, situational hardening |
| CVE-2021-33909 | Exploitation |
| CVE-2021-34866 | Exploitation |
| CVE-2021-43267 | Exploitation |
| CVE-2021-42008 | Exploitation |
| CVE-2022-0185 | Exploitation |
| CVE-2022-0492 | Post-exploitation, situational hardening |
| CVE-2022-25636 | Exploitation |
| CVE-2022-1015/CVE-2022-1015-1016 | Exploitation |
| CVE-2022-23222 | Post-exploitation |
| Tetragon bypass | Exploitation |
We built an AMI on AWS. You can test a few exploits if you want to play. Choose US East (N.Virginia) region and search “vault exploit test” :
We also provide Hardened Linux (Ubuntu for both x86_64 and arm64) on AWS and it got a fancy name: Beyond Compliance. It ships security by default, easily complying with PCI-DSS/GDPR via CIS/STIG benchmark, as well as ModSecurity (Web Application Firewall), VED (Vault Exploit Defense) and more features.
Validation type: From Vault’s perspective
LKRG features
- Checks on SMEP/SMAP disable/enable (p_ed_pcfi_cpu).
- pCFI(pSMEP/sSPC): stack pointer, size, check if return addresses is kernel .text.
- Privilege escalation: check if credentials were modified (p_ed_enforce_validation).
- Kernel text integrity. Modules load checking.
- addr_limit (old kernel version).
- hiding LKRG itself.
VED features
- wCFI: Check if return address is at right callsite.
- wCFI: Callees that may be reused can only be called by specified functions (depend on disabling tail-call optimization and direct call).
- VSPP (Vault self-protection): Check if any essential kprobe was disabled.
- ro guard timer: check if kprobe was globally disarmed.
New process
kprobe point: sys_execve,sys_execveat, sys_ptrace, do_wakeup, wake_up_new_task
Triger point: Start a new process.
Reaction: L1 + L2 + V1 + L3
May be used in doing privilege escalation
kprobe point: native_write_cr4, commit_creds, override_creds, revert_creds, call_usermodehelper_exec, call_usermodehelper, set_current_groups， sys_set*id, sys_capset
Trigger point: These kernel functions may be reused to do privilege escalation, check if they are called from the available call sites and only update credentials if checks are passed.
Reaction: L1 + L2 + V1 + L3 + V1
May be used to bypass LKM security solution
kprobe point: disable_kprobe, p_exploit_detection_exit, text_poke
Triger point: These kernel functions may be reused to bypass LKM solution (LKRG, AKO, Tetragon), check if they are called by available call site or right credentails.
Reaction: L1 + L2 + V1 + L3 + V1 + V3
Post-exploitation checks
kprobe point: mark_inode_dirty, sys_unshare, cap_task_prctl, sys_add_key, security_ptrace_access, generic_permission, security_bprm_committed_creds, security_bprm_committing_creds, wake_up_new_task, sys_ptrace
Triger point: After privilege escalation has happened, the exploit may do something that would trigger capability/credential check. Extra credential checks that may detect exploits are added here.
Reaction: L1 + L2 + V1 + V3
Timer and schedule
LKRG timer
kprobe point: schedule, lookup_fast, __queue_work, wake_up_new_task
Triger point: Detect exploition more frequently.
Reaction: L1 + L2 + V1 + L3 + L5 + L6 + V3
- Interval: 15 seconds by default
VED ro guard
read only data: kptr_restrict, kprobes_all_disarmed
Trigger point: cyclical check if these essential data were corrupted.
Reaction: L4 + V4
- Interval: 1 second
How to build
make && insmod ved.ko