[llvm-dev] [cfe-dev] [RFC] Zeroing Caller Saved Regs

[David Chisnall via llvm-dev]

On 13/08/2020 05:01, Bill Wendling via cfe-dev wrote:
 > Sure, but the authors of the paper claim that it's incredibly
 > difficult to have*only*  COP / JOP gadgets. At some point you'll need
 > to have an ROP gadget:
 >
 > "Usually, the gadgets of ROP end with a return instruction which we
 > called conventional ROP attacks. Call Oriented Programming (COP) [8]
 > and Jump-Oriented Programming (JOP) [9] are the variations of ROP
 > attacks without returns [10]. The variations use gadgets that end with
 > indirect call or jump instruction. However, performing ROP attacks
 > without return instruction in reality is difficult for the reason that
 > the gadgets of COP and JOP that can form a completed gadget chain are
 > almost nonexistent. Actually, adversaries prefer to use combinational
 > gadgets to evade current protection mechanisms."

I don't believe that this transform eliminates the set of useful ROP 
gadgets.  A stack overwrite that writes over the return address can also 
overwrite anything in the spill area, so even if clear all caller-save 
registers, there will be sequences that allow you to modify one of the 
values in the stack frame that you return to.  In C++ codebases, it's 
fairly common to see an object pointer stored in a callee-save register 
and then used for multiple calls, so even without overwriting the return 
address you have a nice entry point for a gadget chain using only 
forward control-flow integrity violations in the rest of the chain.

Most code reuse attacks these days use weird machine compilers to 
analyse a binary (either acquired offline or dumped via a memory 
disclosure gadget).  Reducing the set of gadgets but still giving enough 
for a gadget train does not make it harder for an attacker it just makes 
their compiler work slightly harder.  It's analogous to claiming that 
it's harder for a programmer to write C code for architectures with no 
FPU.  It makes life slightly harder for the toolchain, but not for its user.

As I said, I don't object to adding this feature as a checkbox ticking 
exercise so that the Linux kernel can opt into the same security theatre 
with both gcc and clang, I object only to advertising it as a security 
feature.

David