Recently the news broke that identified a new vulnerability (already listed under CVE-2021-4204) in the eBPF subsystem (for a change) ...
And it is that the eBPF subsystem has not stopped being a great security problem for the Kernel because easily in what was all of 2021 two vulnerabilities were revealed per month and of which we talk about some of them here on the blog.
Regarding the details of the current problem, it is mentioned that the detected vulnerability allows a driver to run inside the Linux kernel in a special JIT virtual machine and that this in turn allows an unprivileged local user to gain privilege escalation and execute their code at the kernel level.
In the problem description, they mention that the vulnerability is due to incorrect scanning of the eBPF programs transmitted for execution, since the eBPF subsystem provides auxiliary functions, the correctness of which is verified by a special verifier.
This vulnerability allows local attackers to increase privileges on
affected Linux kernel installations. An attacker must first obtain the
ability to run low-privilege code on the target system to
exploit this vulnerability.The specific flaw exists in the handling of the eBPF programs. The question results from lack of proper validation of user-provided eBPF programs before running them.
Besides that, some of the functions require the PTR_TO_MEM value to be passed as an argument and the verifier must know the size of the memory associated with the argument to avoid potential buffer overflow problems.
While for functions bpf_ringbuf_submit and bpf_ringbuf_discard, data on transferred memory size is not reported to the verifier (this is where the problem begins), which the attacker takes advantage of to be able to use to overwrite memory areas outside the buffer limit when executing specially crafted eBPF code.
An attacker can exploit this vulnerability to escalate privileges and execute code in kernel context. PLEASE NOTE that unprivileged bpf is disabled by default on most distributions.
It is mentioned that in order for a user to carry out an attack, user must be able to load their BPF program and many recent Linux distributions block it by default (including unprivileged access to eBPF is now prohibited by default in the kernel itself, as of version 5.16).
For example, it is mentioned that the vulnerability can be exploited in the default configuration in a distribution that is still quite used and above all very popular as it is Ubuntu 20.04 LTS, but in environments like Ubuntu 22.04-dev, Debian 11, openSUSE 15.3, RHEL 8.5, SUSE 15-SP4 and Fedora 33, it only manifests if the administrator has set the parameter kernel.unprivileged_bpf_disabled to 0.
Currently, as a workaround to block the vulnerability, it is mentioned that unprivileged users can be prevented from running BPF programs by running the command in a terminal:
sysctl -w kernel.unprivileged_bpf_disabled=1
Finally, it should be mentioned that the problem has appeared since Linux kernel 5.8 and remains unpatched (including version 5.16) and that is why the exploit code will be delayed for 7 days And it will be published at 12:00 UTC, that is, on January 18, 2022.
With that It is intended to allow sufficient time for the corrective patches to be made available of the users of the different Linux distributions within the official channels of each of these and both developers and users can correct said vulnerability.
For those who are interested in being able to know about the status of the formation of updates with the elimination of the problem in some of the main distributions, they should know that they can be traced from these pages: Debian, RHEL, SUSE, Fedora, Ubuntu, Arch.
If you are interested in knowing more about it about the note, you can consult the original statement In the following link.