{"id":100574,"date":"2021-06-22T16:24:20","date_gmt":"2021-06-22T14:24:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-podsisteme-ebpf-pozvolyayushhie-obojti-zashhitu-ot-atak-klassa-spectre"},"modified":"2021-06-22T16:24:20","modified_gmt":"2021-06-22T14:24:20","slug":"uyazvimosti-v-podsisteme-ebpf-pozvolyayushhie-obojti-zashhitu-ot-atak-klassa-spectre","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimosti-v-podsisteme-ebpf-pozvolyayushhie-obojti-zashhitu-ot-atak-klassa-spectre","title":{"rendered":"Vulnerabilities in the eBPF subsystem allow bypassing protection against Spectre-class attacks.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A vulnerability has been identified in the Linux kernel (CVE-2021-33624) that allows the eBPF subsystem to bypass protections against Spectre-class vulnerabilities, enabling the determination of memory contents by creating conditions for speculative execution of certain operations. For a Spectre attack, specific command sequences in privileged code are required to trigger speculative execution of instructions. By manipulating the BPF programs passed for execution, it is possible to generate similar instructions in eBPF and leak kernel memory contents and arbitrary areas of physical memory through side channels. <\/p>\n
The vulnerability is caused by shortcomings in the verifier used to detect errors and invalid activity in BPF programs. The verifier examines possible execution paths of the code but overlooks branching options that are semantically invalid according to the instruction set architecture. During the execution of a BPF program, such branching options that were not accounted for by the verifier can be incorrectly predicted by the processor and executed in speculative mode. For example, when analyzing the 'load' operation, the verifier assumes that the instruction uses a register with an address whose value always stays within certain bounds, but an attacker can create conditions under which the processor attempts to speculatively perform the operation with an address that does not meet the validation conditions. <\/p>\n
The issue manifests starting from kernel release 4.15 and has been mitigated with patches (1, 2, 3, 4). The vulnerability remains unaddressed in distributions (Debian, RHEL, Ubuntu, Fedora, SUSE, Arch). <\/p>\n
Additionally, a note can be made about the performance impact of protections against Spectre-class vulnerabilities. The note summarizes the results of optimizing the rr (Record and Replay) debugger, which was created by Mozilla to debug hard-to-reproduce bugs in Firefox. Caching system calls used to check for the existence of directories reduced the execution time of the 'rr sources' operation for a test project from 3 minutes 19 seconds to 36 seconds. <\/p>\n
The author of the optimization decided to check how performance would change after disabling Spectre mitigation. After booting the system with the 'mitigations=off' parameter, the execution time of 'rr sources' without optimization was 2 minutes 5 seconds (1.6 times faster), while with optimization it took 33 seconds (9% faster). Interestingly, disabling Spectre mitigation not only reduced the execution time of code at the kernel level by 1.4 times (from 2m9s to 1m32s) but also halved user-space execution time (from 1m9s to 0m33s), presumably due to decreased CPU cache efficiency and TLB flushes when Spectre protection is enabled. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"