Hi all, Every year there are new vulnerabilities, and some of them are possible because of ROP attacks. There are a couple things that come to mind to thwart ROP attacks that would rely on compiler changes in particular, instead of a kernel change or hardware change.
I was wondering if anyone in the GCC project might be willing to consider these in order to improve computer security? Idea 1. Use separate stacks for local variables and stack data. - Use RSP for return addresses, as usual. - Use RBP for functions' local storage i.e. to point to a second downward-growing stack that is in the heap, far from the return stack. This way, a buffer overflow (stack smashing attack) would wipe out functions' data but not return addresses, therefore no ROP. I realize that use of two stacks is an old idea, but now that we have many more general purpose registers, using RBP in this way should be economical. Idea 2. ROP depends on gadgets, which are short segments of code ending in RET. The tricky thing about mitigating ROP is that gadgets are in unexpected places i.e. not the end of the function where the main RET instruction is. Wherever a RET opcode byte is found, even if it is inside of an immediate value, it can be used to form a gadget. Therefore to reduce the number of available ROP gadgets, first make sure that all immediate values in the program lack bytes that include RET opcodes, so simply replace 0xCB and 0xCA bytes (on x86) with other values. For example: add RAX, 0xCB01 becomes add RAX, 0xC001 add RAX, 0x0B00 Similarly if a branch instruction's relative offset contains a 0xCB or 0xCA in the low offset byte, put a few NOPs in front of it to ensure that byte will not be a RET. It might be tricky to avoid the ModRM byte 0xCB (as in ADD BL, CL) but it can be done. My 2 cents.
