OpenBSD Journal

OpenBSD now has Trapsleds to make life harder for ROPers

Contributed by pitrh on from the just enough ROP to TRAP yourself dept.

You heard it here (or on tech@) first: Trapsleds are in, and it makes OpenBSD even safer. Work done by Todd Mortimer and submitted to tech@ in the Trapsleds thread was later committed by Theo de Raadt.

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.

Todd

["gas-trapsled-amd64.diff" (text/plain)]

You can read the full thread here, and the commit message here. Snapshots with this code in it should be turning up on a mirror near you soon.

(Comments are closed)


  1. By Anonymous Bastard (79.134.255.200) on

    Even if no attacks are currently known, this could be very useful for bug detection. If a program miscalculated a jump by a few bytes it would never be caught by a NOP slide, whereas this will catch it instantly. And what often happens in software development is that you fix one miscalculation, you often fix a lot of other bugs instantly.

    Good stuff from the OpenBSD devs.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]