Beat SMEP on Linux with Return-Oriented Programming

http://falken.tuxfamily.org/?p=115

by coreyrecvlohe • 15 years ago

35 12 15 years ago

falken.tuxfamily.org

jeffreyg2• 15 years ago

A good paper came out a few years ago that defeats ROP by adding protections to ensure that returns/calls/jumps are only taken if the function was entered at its entry point, and rearranging register allocation if the compiler creates unaligned instructions that can be used to ret/jmp. They say the performance penalty isn't huge, but I guess it must be enough if people aren't implementing it.

[1] G-Free: Defeating Return-Oriented Programming through Gadget-less Binaries (http://iseclab.org/papers/gfree.pdf)

scott_s2• 15 years ago

They say the performance penalty isn't huge, but I guess it must be enough if people aren't implementing it.

There are other, social reasons why it may not be used. Academics are usually evaluated on published papers, so papers are often their end goal. Their code is usually proof-of-concept quality, not production quality. So it's not realistic to be able to take code written by academics and directly integrate it into real software stacks. And the people who are in a position to integrate new features into open source software stacks often have dozens of other features that are also important, so why work on this one? There really needs to be a champion for the idea in the already-existing community for that project.

This work also has the secondary problem of cross-cutting concerns. In order to provide better security in the kernel, they're modifying the assembler. So now you need a champion who works in the assembler, but cares a lot about kernel security.

Good paper, by the way. I've only read the intro, but I'm going to read the rest later. It looks to have a good primer on ROP.

cantankerous• 15 years ago

I think that Shacham paper is the best primer on ROP of all the papers I've read, including the paper mentioned by the parent commentor:

http://cseweb.ucsd.edu/~hovav/dist/geometry.pdf

onars4• 15 years ago

I am the author of the paper on G-Free.

G-Free does not modify the assembler, or any other component on a system. It is a completely independent layer between the compiler and the assembler. And its performance overhead is indeed surprisingly low.

Even then, there are numerous reasons I can think of why it won't immediately be included in a production environment (as won't most cutting edge research).

The first reason being, by definition, G-Free is a compiler based solution. You need the source code in order to build gadget free software. This may not be the best fit for an already established production system. However, I can imagine this system being easily adapted into a binary loader, so that it does its trick when loading a binary into the memory.

Then, you have the issues of compiler verification. You are right in saying that research quality code does not equal production quality. We do have a prototype implementation that works nicely, as described in the paper. But who am I to say it is perfect? Well, we compiled a full system with it, and have been running it without problems since then. But you never have the assurance unless you do some formal verification. I would not compile a critical piece of software (something running on an aircraft, for example) with just any implementation, without having solid ( = formal) proof that the implementation is perfect.

rwmj• 15 years ago

"kernel symbols hiding" ... I always find that to be funny. Once your code is in kernel space, searching for kernel symbols by name is easy. Proof is in the program I wrote called virt-dmesg which uses heuristics to search for the main symbol table, and also for kallsyms if available

http://people.redhat.com/~rjones/virt-dmesg/

Beat SMEP on Linux with Return-Oriented Programming

Related Stories