Vulnerability in eBPF allows bypass protection against Specter attacks

Yesterday we published here on the blog the news about Aya, a library for creating eBPF drivers in Rust and is that the purpose of this is to create more secure drivers or the Prossimo project to ensure memory of the Linux kernel with Rust (two great projects that will give a lot to talk about in the following months).

And is that in a matter of a short time, various vulnerabilities have been reported in which take advantage of bugs in eBPF and that it is an issue in which the kernel developers have not stopped working and perhaps Rust is the solution.

The reason for touching on this topic is that recently the news was released that they have identified "Other" vulnerability in the Linux kernel (CVE-2021-33624) for bypass protection against Specter-class vulnerabilities, since this allows to use the eBPF subsystem to be able to determine the content of the memory as a result of the creation of conditions for speculations of execution of certain operations.

It is mentioned that the vulnerability it is caused by failures in the verifier, which is used to detect errors and invalid activity in BPF programs. The verifier lists the possible code execution paths, but ignores any branching options that are not valid from the point of view of the instruction set architecture semantics.

When running a BPF program, branching options that were not taken into account by the verifier may be incorrectly predicted by the processor and executed in a speculative mode.

On affected systems, an unprivileged BPF program can exploit this vulnerability to filter the contents of arbitrary kernel memory (and therefore all physical memory) through a side channel.

Eg when analyzing the "load" operation, the verifier assumes that the instruction uses a register with an address whose value is always within the specified limits, but an attacker can create conditions under which the processor will speculatively attempt to perform a trade with an address that does not meet the verification conditions.

The Specter attack requires the presence of a specific script in the privileged code, leading to speculative execution of instructions. By manipulating the BPF programs that are passed in for execution, it is possible to generate such instructions in eBPF and filter the contents of kernel memory and arbitrary areas of physical memory through side channels.

Moreover, you can make a note about the performance impact of assets to protect against the Specter class of vulnerabilities.

This note summarizes the results debugger optimization rr (Record and Replay), once created by Mozilla to debug hard-to-repeat errors in Firefox. Caching the system calls used to verify the existence of directories reduced the "rr sources" operation for the test project from 3 minutes 19 seconds to 36 seconds.

The optimization author decided to check how much will change performance after disabling Specter protection. After booting the system with the parameter "mitigations = off", the execution time of "rr sources" without optimization was 2 minutes 5 seconds (1.6 times faster) and with optimization 33 seconds (9% faster).

Interestingly, disabling Specter protection not only reduced runtime of the kernel-level code in 1.4 times (from 2 min 9s to 1 min 32s), it also halved the execution time in the user space (from 1 min 9s to 33s), presumably due to a decrease in the efficiency CPU cache and TLB are reset when Specter protection is enabled.

The problem has appeared since the 4.15 kernel release and has been fixed in the form of patches, which at the moment still do not reach all distributions, so it is recommended to users that these days they are making the relevant updates as soon as they receive the notifications.

Si you want to know more about it, you can check the details In the following link.


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.