Tech Support
Documentation
Login
Contact Us
Understanding the new AF_VSOCK Linux kernel vulnerability
February 17, 2021 - TuxCare PR Team
The discovery of a new Linux kernel vulnerability is not a major surprise in its own right. It happens all the time. However, sometimes it appears as if, whenever a security researcher goes looking, the researcher discovers a new, serious vulnerability in the Linux kernel – and that it happens just too often for comfort.
This February, a new vulnerability was reported in a relatively obscure corner of the Linux kernel – in a function that facilitates communications between virtual machine host and guest. Though just discovered, it is already listed as CVE-2021-26708.
In this article we outline the vulnerability, explain how it emerged, and point to the potential risks the new vulnerability holds.
Content
Introduction to the vulnerability
When did it get into the kernel?
Hang on, we don’t rely on virtualization…
How does the vulnerability work?
Which other AF_VSOCK vulnerabilities exist?
Patch fast, and patch thoroughly
Consider live patching with KernelCare
Introduction to the vulnerability
In February, a researcher discovered that the Linux implementation of AF_VSOCK allows an attacker to launch a privilege escalation attack. The ability to do so relies on the fact that a race condition is created under certain circumstances when AF_VSOCK is called, which leads to the opportunity to bypass key security mechanisms – SMEP and SMAP.
It is interesting that, in the case of this vulnerability, the weakness is found in a function of the Linux kernel where vulnerabilities are found relatively rarely. This is only the third vulnerability found in AF_VSOCK so far, we’ll take a quick look at two others – CVE-2013-3237 and CVE-2018-14625 – later in this article.
This is a relatively low number of vulnerabilities in a particular corner of the Linux kernel – consider the fact that there are fourteen futex vulnerabilities in the Linux kernel, for example.
When did it get into the kernel?
AF_VSOCK was first introduced into the Linux kernel to facilitate virtual machine communications. The code specific to this vulnerability was introduced in 2019 – it is code that implements multi-transport support in AF_VSOCK.
In November 2019, the code was merged into Linux kernel version v5.5-rc1. As a result, many distributions that incorporated that kernel version and later now incorporates the affected AF_VSOCK implementation.
AF_VSOCK is included in all major Linux distributions, including for example Red Hat Enterprise Linux (RHEL) and Ubuntu, which is why both of these vendors have reported the new AF_VSOCK vulnerability as a concern.
Hang on, we don’t rely on virtualization…
It doesn’t matter. The issue lies in the fact that, even if you do not make use of AF_VSOCK in your applications, the AF_VSOCK module is included in the Linux kernel and AF_VSOCK is always ready to be loaded as soon as it is requested by a program. This autoloading ensures that the code is available whenever a virtualization host tries to communicate with a virtual machine.
A hacker can therefore simply create an application that requests a “dummy” VSOCK. By calling AF_VSOCK the hacker causes the operating system to auto-load AF_VSOCK – which then allows the hacker to exploit the new vulnerability.
So, even if you do not make use of virtualization, the presence of the AF_VSOCK module in most common Linux distributions implies that your system is vulnerable too.
How does the vulnerability work?
As we suggested earlier in this article, the vulnerability can easily be triggered by a malevolent actor when that actor puts in a VSOCK request. There are currently no live exploits of this vulnerability, but in this section, we will cover some of the key concepts around this vulnerability to help highlight how it may be exploited in the future.
It requires a local account
First, we address an aspect that somewhat reduces the potential severity of this particular vulnerability. To be able to exploit the weakness in this vulnerability the intruder will require access to a local account. This contrasts with many other vulnerabilities that can be more easily exploited remotely.
In other words, the attacker will need prior local access to your system to be able to exploit this vulnerability. It does not involve a remote exploit where an attacker can remotely attack your system without existing access to your system.
That said, this vulnerability is still dangerous because it involves something called privilege escalation.
What is privilege escalation?
In any system, it is common – and good practice – to limit the permissions (or privileges) granted to a user. A super admin or root user for example will have broad, unrestricted permissions to execute instructions in an operating system, but a responsible sysadmin will never grant such broad access to every user – and to every application.
Instead, more limited access is granted. Good practice would mean that sysadmins grant only the privileges necessary for the user or the application to execute their duties.
However, basic privileges can act as a steppingstone. Attackers can exploit a flaw or vulnerability or indeed a programming or configuration error to gain higher (or elevated) privileges in a system. While the initial permissions for a user may be highly restrictive, through privilege escalation an attacker may be able to gain expansive access – often this might be full root access to a system.
Privilege escalation can be difficult to detect, and the best way to guard against this type of attack is to ensure that the underlying vulnerability is protected. By applying a patch, for example.
By the way, what is VSOCK?
Today, it is common to manage computing workloads using virtualization. You can read more about virtualization here, but for the purposes of this article it is worth understanding a few things about virtualization.
Virtualization implies that several operating systems (the guests) are hosted on a single computer – and that these guest operating systems are managed by an overarching piece of code called a hypervisor (the host).
Guest operating systems act like distinct, discrete operating systems just like they normally would if hosted 1:1 on a computer. However, eventually, there is a need for the guest operating system to communicate with its host – the hypervisor.
One way to do it would be to use the virtual networking established by the hypervisor – essentially using Ethernet and TCP/IP to communicate. However, this method is not reliable and requires the configuration of network interfaces on the guest.
That’s why VSOCK was added to the Linux kernel. VSOCK makes it easy to facilitate communications between guest and host. It can be used by user level applications on the virtual machine. It is compatible with TCP and UDP, and in Linux the protocol family is defined as AF_VSOCK.
SMP and race conditions
The other key thing you should understand about enterprise-grade virtualization is that it relies heavily on processor features – virtualization must be supported in the CPU hardware, to start off with. Furthermore, to efficiently manage competing demands for processor capabilities, virtualization relies on cutting-edge processer technology, including the ability to manage workloads across multiple processors in one system.
It uses something called symmetric multiprocessing (SMP) to achieve this. In simple terms, the operating system – or indeed the hypervisor – manages concurrent processes across multiple CPUs all within one system sharing the same memory.
SMP can get complex, particularly around the access to shared data. It can happen that two or more processes try to access the same data – but that it is not clear which of the processes will be the first to get access to this data. Both processes are “racing” to get access to the data, which creates what’s called a race condition.
Race conditions can be exploited by hackers to interfere with an otherwise secure process and that is why the new AF_VSOCK vulnerability can become dangerous – the incorrect code implementation introduced in November 2019 creates the opportunity for a race condition to emerge.
SMAP/SMEP security features
Given the need to facilitate communications between operating systems, AF_VSOCK code executes at a very low level. This can create a condition where attackers exploiting code at such a low level can rapidly gain power over a system.
The latest series of Intel CPUs have built-in features to protect against processor-level vulnerabilities – it’s called supervisor mode execution protection (SMEP) and supervisor mode access prevention (SMAP). Linux supports these features which are intended to prevent the kernel from unintentionally accessing user space memory.
However, the conditions that develop because of the newly discovered vulnerability in AF_VSOCK allows an attacker to bypass SMEP and SMAP. This, in turn, opens the door to a privilege escalation attack.
The impact
There are currently no exploits in the wild and it is difficult to accurately predict the impact of this new vulnerability. Nonetheless, given the low-level operations involved and the clear potential for a privilege escalation attack, we would advise that organizations take this vulnerability seriously. A patch is likely on the way and the faster your organization applies this patch, the better.
What is at risk?
In short, and is often the case, the answer is that everything is at risk. The new AF_VSOCK vulnerability could be the entry point to a large-scale breach in your networks. By pivoting off a privilege escalation attack an intruder can gain unrestricted access to a PC, or a server.
This can be a steppingstone to much broader access: the compromised system may be in a trusted role, and the attacker could abuse these privileges to accomplish their goals.
Who is affected?
Everyone relying on a major distribution that uses a kernel released after November 2019 right through early February 2021. This includes Red Hat Enterprise Linux (RHEL) 8, CentOS 8, and Ubuntu 20.10.
It doesn’t matter where in your organization the operating system is deployed, or the importance of that deployment: your organization is at risk as long as this vulnerability remains unpatched.
Which other AF_VSOCK vulnerabilities exist?
At the time of writing the community is aware of two other vulnerabilities that affect AF_VSOCK in the Linux kernel:
- CVE-2013-3237. In this vulnerability, identified in 2013, researchers found that the vsock_stream_sendmsg function does not initialize a specific length variable. In turn, this omission allows a local user to use a specifically crafted recvfrom or recvmsg system call to get sensitive information from the kernel stack memory.
- CVE-2018-14625. Discovered in 2018, this AF_VSOCK vulnerability also involves the emergence of a race condition – this time between two functions, connect() and close(). By exploiting this vulnerability an attacker could perform an uncontrolled read of kernel memory from inside a virtual machine guest.
Neither of these vulnerabilities has received much coverage and there are no known exploits – but that does not mean that no exploit will be found, nor that there is no unknown exploit actively being used in the wild.
Patch fast, and patch thoroughly
The two AF_VSOCK vulnerabilities we listed above have been patched and we expect the newly-discovered vulnerability to also see a fix in short order. In turn, the various distributions that rely on the current Linux kernel will release OS patches that ensure that the new vulnerability does not pose a danger.
However, patches need to be applied to be effective. As an organization, you must ensure that kernel patches are applied across your Linux machines. You need to do so rapidly, and consistently. Just a single unpatched machine can leave your entire technology estate open to attack.
Consider live patching with KernelCare
That said, at KernelCare, we understand how difficult it is to consistently patch. Patching requires time and resources, both of which can be in short supply. Worse, patching can be disruptive as server reboots lead to service downtime and unhappy users and customers.
KernelCare offers automated patching for several Linux distributions. This live patching service does not require server restarts – instead, patching occurs without disrupting services. In other words, your organization can patch consistently – without the costs in labor, or disruption.
Conclusion
The relatively obscure corner of the Linux kernel in which the new vulnerability was discovered highlights just how broad and unpredictable today’s vulnerability landscape is. There is really no predicting where and when a new threat can emerge.
Nonetheless, there are tried and true methods to protect against emerging vulnerabilities. Regular patching is one clear route to continuously safe operations. Find patching time-consuming or too disruptive? Take a look at KernelCare’s automated, rebootless patching here.
