Risk
11/23/2008
12:00 AM
Commentary
Commentary
Commentary
50%
50%

Security and Return-Oriented Programming

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 designer

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. 

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8921
Published: 2015-03-01
The IBM Notes Traveler Companion application 1.0 and 1.1 before 201411010515 for Window Phone, as distributed in IBM Notes Traveler 9.0.1, does not properly restrict the number of executions of the automatic configuration option, which makes it easier for remote attackers to capture credentials by c...

CVE-2014-9676
Published: 2015-02-27
The seg_write_packet function in libavformat/segment.c in ffmpeg 2.1.4 and earlier does not free the correct memory location, which allows remote attackers to cause a denial of service ("invalid memory handler") and possibly execute arbitrary code via a crafted video that triggers a use after free.

CVE-2014-9682
Published: 2015-02-27
The dns-sync module before 0.1.1 for node.js allows context-dependent attackers to execute arbitrary commands via shell metacharacters in the first argument to the resolve API function.

CVE-2015-0655
Published: 2015-02-27
Cross-site scripting (XSS) vulnerability in Unified Web Interaction Manager in Cisco Unified Web and E-Mail Interaction Manager allows remote attackers to inject arbitrary web script or HTML via vectors related to a POST request, aka Bug ID CSCus74184.

CVE-2015-0884
Published: 2015-02-27
Unquoted Windows search path vulnerability in Toshiba Bluetooth Stack for Windows before 9.10.32(T) and Service Station before 2.2.14 allows local users to gain privileges via a Trojan horse application with a name composed of an initial substring of a path that contains a space character.

Dark Reading Radio
Archived Dark Reading Radio
How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.