Machinecode Diversification in JIT

[Lichtso]

Based on:

Homescu, Andrei, et al. "Librando: transparent code randomization for just-in-time compilers"
Proceedings of the 2013 ACM SIGSAC conference on Computer & Communications Security. 2013."

Implemented Techniques:

• Instruction Address Randomization: Occasional emission of additional no-op instructions
• Input Sanitization: Encryption of user provided values such as immediate values and offsets
• Environment Obfuscation: Encryption of registers which the compiled program uses under the hood:
  • R10 - JitProgramArgument: The memory_mapping and bound syscall_context_objects
  • RBP - Stack frame pointer

[jon-chuang]

So I guess the purpose here is to generate a local runtime specific binary with randomised executable address space to defend against reentrancy attacks that only have knowledge of the source code/eBPF bytecode.

[jackcmay]

In our environment I'm having a hard time figuring out what attack vectors this work is intending to address. Can you help me understand?

[Lichtso]

@jackcmay I updated the description of the PR with a link to the paper in which the attacks and their prevention are described in detail.

[dmakarov]

In current implementation address randomization seems to be always enabled. Would it be possible to add an option that would disable this?

[Lichtso]

@dmakarov I added config options for both techniques here:

rbpf/src/vm.rs

Line 185 in d86853f

/// Ratio of instructions per no-op for randomization in the JIT code emitter

E.g. setting instructions_noop_salting_ratio to 0 would result in no randomization.

Edit: Also, all randomization happens at x86 level now, not at BPF level anymore. So it should be transparent for the tracer (but not for GDB / LLDB).

[jackcmay]

@jackcmay I updated the description of the PR with a link to the paper in which the attacks and their prevention are described in detail.