Hackers of India

Randomization Can’t Stop BPF JIT Spray

 N Asokan  , Filippo Bonazzi  , Elena Reshetova 

2016/11/04


Presentation Material

Abstract

Linux Berkeley Packet Filters (BPF) is a mechanism that was originally introduced in Linux kernel 2.5 as a way to perform fast line-speed filtering of network packets. In Linux kernel 3.0 a Just-In-Time (JIT) compiler was added, effectively transforming it into a general-purpose mechanism to safely support interpreted code injected into a Linux kernel. In fact, it has been even called the “universal in-kernel virtual machine” [1]. Nowadays BPF usages are not limited just by packet filtering, but are also used in mechanisms such as seccomp [2], various tracepoints [3] and others, making it an attractive target for an attacker. The original JIT-spray attack against BPF JIT compiler was first described in 2012 [4] with the proof of concept implementation available [5]. It used the ability to pass the exploit payload as constants in BPF instructions and the fact that filter address was relatively easy to guess given enough filters loaded in the kernel. After that the upstream kernel merged patches that addressed the attack by randomizing the load offset of a filter. However, this didn’t remove the actual problem (possibility of providing payload in BPF instructions) but only stopped the original proof of concept code from working. It was thought that this is a sufficient mitigation to the attack because the difficulty of guessing the correct load offset was very high.

This talk will present a modified proof of concept code [6] that demonstrates the possibility of successful BPF JIT-spray attack on the 4.4 upstream Linux kernel. The idea of the modification is to create long enough filters to make sure they spawn beyond one memory page and render the payload in a way that random jumps to page start with a small offset search is enough to guess the payload address. The attack was first announced on Linux kernel-hardening mailing list in march this year and got a considerable attention in the grsecurity forum post [7] and LWN front page [8].The kernel patches that address this attack were merged to upstream kernel [9] and expected to appear for 4.7.

Sources:
1
2
3
4
5
6
7
8
9