On 5/10/19 9:17 AM, Zack Vu wrote: > 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. Bernd and others within Red Hat looked at ROP mitigation a while back. We ultimately stopped development of gadget spoilage due to the emergence of CET and instead we've put our focus there.
While CET won't help older processors, it's my belief it's the right first major step in ROP mitigation. At this point we believe RHEL 8 is fully ready to use CET when processors hit the streets. I haven't tracked Fedora as closely, but if it's not ready it shouldn't be hard to make it ready. I suspect other distros have similar plans around CET. I'm not aware of anyone seriously looking at separate stacks for GCC right now. To some degree the stack protector serves the same purpose without separating stacks. Jeff
