Frequently Asked Questions
How many kernel vulnerabilities does VED protect against today? What are the kernel versions supported by VED?
Linux kernel has roughly 120 public vulnerablity (with CVE number) each year. The memory corruption mitigation can be done in 3 separate stages: Pre-exploitation stage, Exploitation stage and Post-exploitation stage. VED is highly focus on the later twos and can’t do anything about Pre-exploitation stage. We evaluated many exploit techniques in large number of vulnerablities from MITRE’s CVE + Ubuntu security tracker + public PoC. Our evaluation ratio is greater than the public PoC/Exploit, but less than Ubuntu security Tracker. VED’s current mainline development and testing is based on the Linux kernel v4.19 and v5.15. Some users are still running VED on CentOS 7.x (v3.10).
What if a new exploit technique/vector arises?
We continue to develop protection features against new attack methods.
Can VED defeat container escape?
Yes, if the attacker use a container as a foothold and try to take control over the host by launching the attack on Linux kernel, e.g: CVE-2021-22555.
How much of performance hit does VED have?
VED has less than 1% of performance impact in small-plt (CPU-Intensive) test while the impact could be more than 30% in I/O-intensive scenario.
VED is loaded as LKM (Linux kernel module), does each kernel version need to build the VED?
Which hook mechanism does VED use? Does it have compatibility issue with LSM?
VED uses kprobe/ftrace to implement the hook mechanism. Debian enables AppArmor by default and CentOS enables SELinux by default. VED works with Debian and CentOS perfectly. VED offers a full-featured LKM version and an eBPF version for cloud-native auditing purposes, the latter of which does not need to be implemented through a hook.
What hardware architectures are supported by VED?
x86_64 and arm64. Arm64 is only used on AWS Gratiton2 (armv8.2) and Raspberry 4 (armv8.0).
What’s typical scenario VED can kick in?
From risk assessment’s perspective, 1) The containers in a cloud-native environment share the Linux kernel, in which container escape will lead to the compromise of the whole cluster. 2) Linux kernels running on Infotainment and T-Box (AUTOSAR AP) face huge risks from the independent SoC, e.g: WiFi and Bluetooth. There are some assets are more important than others, e,g: 1) SSO (Single Sign-On) based Zero Trust solution. 2) Control nodes in the cloud environment such as Kubernetes master node, OpenStack Nova scheduler, etc. 3) Key management servers, such as nodes that generate and distribute AKs (Access Keys), identity service nodes (Keystone) in OpenStack clusters, etc.
VED uses a third-party open source code, and the Linux kernel itself follows the GPL license, will the current open source subscription model violate GPL compliance?
VED uses the same open source subscription model as SuSE, RedHat and PaX/GRsecurity, that is, HardenedVault will sign an open source subscription agreement with the customer, some of which includes: 1) HardenedVault shares the VED code with customers 2) HardenedVault will terminate the service if the customer violates the agreement. But the source code customer received is still GPL.
Are all HardenedVault products and solutions on the same terms as VED?
Open source subscription terms are similar, but not all products are based on the GPL, such as VaultFuzzer, which is based on the Apache license 2.0.