Hacker News Reader

Comment by pizzalife | Hacker News Reader

Removing RET instructions won't make your program unexploitable. Especially on architectures like x86_64 where you can get so many possible gadgets from a standard library.

Trying to make software mechanisms like this that span multiple architectures feels like a relic of the past. These days you need to use processor-specific features like ARM pointer authentication.

View on HN

It's not meant to be 100% reliable. Also they clearly state that variable length instruction architectures (like x86) are harder to protect. And if you can use something better then great, use it. You can then disable this mechanism.

This misses the point of how ROP works, and is in fact why previous attempts at ROP gadget reduction were flawed: it only takes a handful of gadgets to make a chain. Trying to protect control flow requires more sound approaches than this.

At the time, Todd was testing with whatever the popular rop compiler was, and it wasn't able to chain anything using libc. Even on amd64 you can restrict which gadgets are available. Maybe you can find other approaches with a careful hand search, but I think knocking out the biggest exploit generator is hardly flawed in a practical sense.

People don't generate exploits using popular ROP compilers.

what are popular ROP compilers used for then?

CTF challenges mostly

so they're used in combination with already known exploits but you're saying no one uses them during the development of exploits?

No, they’re mostly toys and demos. They’re not an accurate representation of real-world exploit development.

oh i must be confused about what a CTF challenge is

CTF challenges are to cooking competitions what exploit development is to being a restaurant cook. There are time limits, practicality is less of a concern, and everyone knows that toy constraints are added because nobody wants to watch you stare at IDA for three weeks

Say, if hardware checked that RET transfers control to a place that's immediately preceded by a CALL instruction, would that help?

It would help but it wouldn’t solve ROP. I think it would probably be less useful than gadget reduction, honestly, since there are a lot of useful sequences after a call instruction.

It would not help at all. See (all of, but especially) section 5.4 of N. Carlini, A. Barresi, M. Payer, D. Wagner, and T.R. Gross, "Control-Flow Bending: On the Effectiveness of Control-Flow Integrity," in proc. USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical...

That would disable certain mechanisms that are occasionally useful. For example, to implement user-mode context switches and function hooking.

ARM's Branch Target Identification does something similar to that (but for jumps & calls, not returns).

A shadow stack of return addresses would help.

Not to mention there are other methods, like JMP oriented programming (someone’s even written some papers on that, and tools for it).

Also worth noting: the mov being Turing complete paper.

Reply on news.ycombinator.com