A Final Return for OpenBSD Anti-Return-Oriented Programming Mitigations

16 points by fro

orib

The short summary: OpenBSD mitigations are pretty effective at removing hidden sequences of instructions ending with a ret. Unfortunately, there are other sources of instruction sequences ending with a ret, not just misaligned instructions. For example, functions tend to end with ret, and those returns can also be used as gadgets.

You don't need many gadgets to create a Turing machine, so the mitigation doesn't help so much.

dpc_pw

We compare our GCC-ported standalone utility to the original OpenBSD LLVM mitigation and discovered that our standalone utility is weaker compared to the original LLVM-based mitigation. However, due to the overall weak reduction in gadgets for both the LLVM-based and GCC-based implementations, we conclude that seemingly obvious mitigations may prove to be anything but, and caution providing security improvements without significant testing and evaluation.

I'm looking at the paper, and I might be misunderstanding something, but it looks like these ROP mitigations barely remove any gadgets (places that attacker can use in their ROP attack), and with noticeable binary size and performance overhead? So basically ... it's all rather meh?

mbuhl

This shows the findings described in https://lobste.rs/s/tuyk3l/semi_retirement_really_changing_my

j4m3s

I'm wondering if this could be helpful as a high-level signal of active exploitation. Meaning, if instead of crashes, I get a SIGTRAP, instead of a more generic SIGSEGV or something. Then, this could be interesting to monitor for security purposes ? As the question is usually not if people are gonna get inside but how/when/where. I'm curious to hear what other people would think of this :)