Two new vulnerabilities in eBPF allow bypass protection against Specter 4

Specter logo

Recently the news broke that two vulnerabilities were identified in linux kernel that allow to use the subsystem eBPF to bypass protection against Specter 4 attack (SSB, Speculative Store Bypass). It is mentioned that by using an unprivileged BPF program, an attacker can create conditions for the speculative execution of certain operations and determine the content of arbitrary areas of kernel memory.

The Specter attack method 4 relies on restoring the data trapped in the processor cache after discarding the result of speculative execution of operations when processing interleaved read and write operations using indirect addressing.

When a read operation follows a write operation, the offset of the reading direction may already be known due to similar operations (read operations are performed much more often and reading can be done from cache) and the processor can speculatively read before writing, without waiting for the indirect write direction offset to be calculated.

If, after calculating the offset, an intersection of memory areas for writing and reading is detected, the processor will simply discard the read result already obtained speculatively and repeat this operation. This function allows the read instruction to access the previous value in some direction while the save operation is still pending.

After ruling out a failed speculative trade, traces of its execution remain in the cache, after which one of the methods to determine the contents of the cache can be used to retrieve it based on analysis of changes in cache access time and cached data.

Note that each topic can be abused independently of the other, relying on in errors that do not overlap.

The PoCs have been privately shared with the maintainers of the BPF subsystem to help with arrangement development.

The first vulnerability CVE-2021-35477: it is caused by a flaw in the validation mechanism of the BPF program. To guard against the Specter 4 attack, the checker adds an additional instruction after potentially troublesome save operations in memory, storing a zero value to offset traces of the previous operation.

It was assumed that the zero write operation would be very fast and would block speculative execution as it depends only on the BPF stack frame pointer. But, in fact, it was possible to create conditions in which the instruction leading to speculative execution has time to execute before the preventive save operation.

The second vulnerability CVE-2021-3455: is related to the fact that when the BPF checker detects potentially dangerous save operations in memory, the uninitialized areas of the BPF stack, the first write operation in which it is not protected, are ignored.

This feature leads to the possibility of performing a speculative read operation, depending on the uninitialized memory area, before executing the store instruction. The new memory for the BPF stack is allocated without checking the content that is already in the allocated memory, and in the stage before the BPF program starts, there is a way to manage the content of the memory area, which will then be allocated to the BPF stack.

The available solution re-implements mitigation techniques to continue recommended by CPU vendors and available in mainline kernel git repository.

Finally, it is mentioned that the maintainers of the eBPF subsystems in the kernel obtained access to an exploit prototype that demonstrates the possibility of carrying out attacks in practice.

The problems are fixed in the form of patches, which will be included in the next Linux kernel update, so the updates for the different distributions will be starting to arrive during the next few days.

Source: https://www.openwall.com/


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.