Contributed by pitrh on from the just enough ROP to TRAP yourself dept.
Todd's message to tech says,
I have attached a patch that converts NOP padding from the assembler into INT3 padding on amd64. The idea is to remove potentially conveinent NOP sleds from programs and libraries, which makes it harder for an attacker to hit any ROP gadgets or other instructions after a NOP sled.
NOP sleds are used for text alignment in order to get jump targets onto 16 byte boundaries. They can appear both in the middle of a function and at the end. The trapsleds implemented in this diff convert NOP sleds longer than 2 bytes from a series of 0x66666690 instructions to a 2 byte short JMP over a series of INT3 instructions that fill the rest of the gap. Programs that would have normally just slid through the NOP sled will now jump over. An attacker trying to hit the NOP sled will now get a core dump.
I have been running this on my system for over a week without any apparent ill effects. Specifically, there don't appear to be any performance penalties associated with doing this. A full base build on a system completely converted over to this took slightly less time to complete than the same build on a normal system, and my synthetic testing shows trapsleds perform similarly to nopsleds (performance difference was <1%, which is within error over multiple runs).
If people like this, I can do up the equivalent diff for clang.
Things that could could be improved:
1. For padding inserted at the end of a function, the JMP is unnecessary, and could also be a 0xCCCC. I am going to have a go at gcc to see if I can coerce it into distinguishing end-of-function padding from padding that is intended to be executed. If some kind soul with gcc experience knows where I should look, any pointers would be welcome - my previous attempt was not fruitful.
2. This patch also hits NOP sleds > 8 bytes on i386. We could also hit the NOP sleds between 3 and 7 bytes if there are no objections.
Comments and suggestions are welcome. Thanks to Theo for suggesting it in the hallway track at BSDCan.
(Comments are closed)