In the words of its author:
I have attached a patch that converts NOP padding from the assembler into INT3 padding on amd64. The idea is to remove potentially convenient 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.
I don’t think that there is a single use-case for this: NOP sleds were useful back in the days where the stack was executable and ASLR non-existent or not random enough; to prefix your shellcode with to accommodate environment variations. But nowadays, nobody is using such constructions any more.
TRAPSLED doesn’t make hitting gadgets harder: if you can bypass ASLR, odds are
that you can either jump before or after it, and since those traps are prefixed
jmp to allow the control-flow to jump over them, they won’t alter a
But on the other hand, this is a super-cheap change, that doesn’t introduce complexity at all, and might help to catch some misalignment bugs, but this definitively isn’t, by any means, a security feature.
It’s amusing to notice that Microsoft Visual Studio also uses
int3 as padding since at
least its 2010
edition, and that it never was branded as a security mechanism.
In 2019, Kees Cook changed
the Linux kernel’s functions padding from
Instead of using 0x90 (NOP) to fill bytes between functions, which makes it easier to sloppily target functions in function pointer overwrite attacks, fill with 0xCC (INT3) to force a trap.
#TRAPSLED is a revolutionary OpenBSD mitigation against COOP, a bleeding edge attack technique.
NOP sliding into ROP gadgets is not a thing btw
Has anyone nominated “trapsled” for the @PwnieAwards yet?
My brain had decided to selectively remove any trace of trapsled :)
This comes from the same people responsible for trapsled, so … https://email@example.com/msg39742.html
Shadow-mitigating (designing a mitigation without being informed by actual data), OpenBSD edition: https://marc.info/?l=openbsd-tech&m=149792179514439&w=2 (HT @bleidl)