• XSS.stack #1 – первый литературный журнал от юзеров форума

Видео An Analysis of Speculative Type Confusion Vulnerabilities in the Wild [BlueHat IL 2022]

weaver

31 c0 bb ea 1b e6 77 66 b8 88 13 50 ff d3
Забанен
Регистрация
19.12.2018
Сообщения
3 301
Решения
11
Реакции
4 622
Депозит
0.0001
Пожалуйста, обратите внимание, что пользователь заблокирован
Видео

youtube.com/watch?v=hU3VbQkV2d0

Spectre v1 attacks, which exploit conditional branch misprediction, are often identified with attacks that bypass array bounds checking to leak data from a victim program's memory. Perhaps as a result, the Linux kernel attempts to defend itself from Spectre v1 attacks by protecting array accesses.

Generally, however, Spectre v1 attacks can exploit any conditional branch misprediction. This talk will analyze the vulnerability of the Linux kernel to such a new Spectre v1 attack vector, called speculative type confusion, which uses branch misprediction to make the kernel execute with variables holding values of the wrong type and thereby leak memory content.

Our analysis described in the talk finds multiple exploitable and potentially-exploitable speculative type confusion attacks on the Linux kernel. We will demonstrate a full memory disclosure attack, capable of reading all of physical memory, by bypassing Linux eBPF's Spectre mitigations (fixed in June 2021 following a responsible disclosure process). We will show that speculative type confusion can occur as a result of compiler optimizations, which developers cannot control or reason about. We will analyze Linux's approach for reducing retpoline overhead, and show that broadly adopting its approach would lead to many speculative type confusion issues, due to speculatively executing a valid but wrong target of an indirect branch. Finally, we will show that existing Spectre mitigations capable of defeating speculative type confusion impose unacceptable overheads.

Overall, this talk will show that speculative type confusion is much more insidious than array bounds check bypasses, and makes it hard if not impossible for developers to reason about code and apply Spectre mitigations. Consequently, Spectre mitigations needs to be rethought, and more hardware support seems to be required to efficiently block the attacks.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх