5 ms·
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 stand
by pizzalife 3y ago
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.
- H8crilA 3y agoIt'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.
- saagarjha 3y agoThis 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.
- Joker_vD 3y agoSay, if hardware checked that RET transfers control to a place that's immediately preceded by a CALL instruction, would that help?
- deadbeeves 3y agoThat would disable certain mechanisms that are occasionally useful. For example, to implement user-mode context switches and function hooking.
- saagarjha 3y agoIt 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.
- IshKebab 3y agoARM's Branch Target Identification does something similar to that (but for jumps & calls, not returns).
- cryptonector 3y agoA shadow stack of return addresses would help.
- hovav 3y agoIt 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-sessions/presentation/carlini https://www.usenix.org/conference/usenixsecurity15/technical...
- tedunangst 3y agoAt 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.
- saagarjha 3y agoPeople don't generate exploits using popular ROP compilers.
- fullspectrumdev 3y agoNot 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.