I was under the impression that NOP sleds were inserted by the attacker when they can't quite be sure where exactly their code will begin executing. They just transfer execution to about the region the NOP sled will be, and then slide through to the start of the payload.
Modifying NOP sleds at compile time is not going to defend against this.
OpenBSD uses W^X aka DEP aggressively. In fact, for OpenBSD 6.1 a program can't even disable W^X unless the binary was mounted on a filesystem with the wxallowed option.
Thus, attackers can't insert NOP sleds. They have to rely on the sleds already in the code. From what I gather from the announcement, toolchains often insert NOPs as padding, inadvertently creating NOP sleds. This is an attempt to fix that.
Re:Trapsleds
by possiblydave on Monday June 26, 2017 @04:00AM
(#14634900)
I am absolutely fascinated by this! I have relatively little experience at this level of computing outside of developing some pet project VMs and a bit of 68k assembly in college. Can you expound on the purpose of a NOP sled and why that specific construct lends itself to systems exposed to specific harsh conditions?
The best example I can think of is a set of instructions on a medium. You've got jumps as a normal part of programming at this level. If the address of the jump is corrupted by an environmental factor (e.g. Hard radiation), then the jump
may end up in lalaland. A sled in this context would be placed at the end of and in between sets of instructions
with a jump back to a safe location to restart. So a jump to an invalid location or past the instruction set would have a chance of recovering back to a valid subroutine.
Unless you were making a joke about context-free replacement.