Channels ▼

Jonathan Erickson

Dr. Dobb's Bloggers

Security and Return-Oriented Programming

November 23, 2008

You don't have to stray too far from the financial pages to know that returns of any kind aren't much to brag about these days. You could say the same thing about "return-oriented programing." In a nutshell, return-oriented programming security attacks start out like familiar attacks, in which attackers take advantage of a programming error in the target system to overwrite the runtime stack and divert program execution away from the path intended by the system's designers. But instead of injecting outside code, return-oriented programming lets attackers create any kind of computation or program by using the existing code. Sounds like fun, eh?

The term "return-oriented programming" describes how "good" instructions can be strung together to build malicious programs, which need to end with a return command. Erik Buchanan and Ryan Roemer, grad students at the University of California, San Diego, have showed that the process of building these malicious programs from good code can be automated by grouping sets of instructions into "gadgets," then abstracting much of the tedious work behind a programming language and compiler.

In a 2007 paper,  The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) , UC San Diego's Hovav Shacham  described how return-oriented programming could be used to force computers with the x86 architecture to behave maliciously without introducing any bad code into the system. However, the attack required hand coding and relied on a quirk of the x86 design.

Now, Buchanan and Roemer have taken Shacham's work to the next level by showing that the process of building bad programs from good code using return-oriented programming can be automated, and that this vulnerability applies to RISC computer architectures--not just the x86 architecture.

"Most computer security defenses are based on the notion that preventing the introduction of malicious code is sufficient to protect a computer. This assumption is at the core of trusted computing, anti-virus software, and various defenses like Intel and AMD's no execute protections. There is a subtle fallacy in the logic, however: "Simply keeping out bad code is not sufficient to keep out bad computation," says UC San Diego professor Stefan Savage, a coauthor with Buchanan, Roemer, and Shacham of When Good Instructions Go Bad: Generalizing Return-Oriented Programming to RISC Return-oriented Programming. "You can create any kind of malicious program you can imagine--Turing complete functionality," adds Shacham.

"The threat posed by return-oriented programming, across all architectures and systems, has negative implications for an entire class of security mechanisms: Those that seek to prevent malicious computation by preventing the execution of malicious code," say the authors in When Good Instructions Go Bad: Generalizing Return-Oriented Programming to RISC Return-Oriented Programming. 

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.