OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
OpenBSD now has Trapsleds to make life harder for ROPers
Contributed by pitrh on Thu Jun 22 06:55:25 2017 (GMT)
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.

[topicopenbsd]

<< KARL - kernel address randomized link | Reply | Flattened | Expanded | d2k17 Hackathon Report: Alexander Bluhm on Network Stack Improvements and more >>

Threshold: Help

Related Links
more by pitrh


  Re: OpenBSD now has Trapsleds to make life harder for ROPers (mod 12/16)
by Anonymous Bastard (79.134.255.200) on Thu Jun 22 11:03:36 2017 (GMT)
  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.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 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 April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. Some icons from slashdot.org used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]