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
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2208
Published: 2014-12-28
CRLF injection vulnerability in the LightProcess protocol implementation in hphp/util/light-process.cpp in Facebook HipHop Virtual Machine (HHVM) before 2.4.2 allows remote attackers to execute arbitrary commands by entering a \n (newline) character before the end of a string.

CVE-2014-2209
Published: 2014-12-28
Facebook HipHop Virtual Machine (HHVM) before 3.1.0 does not drop supplemental group memberships within hphp/util/capability.cpp and hphp/util/light-process.cpp, which allows remote attackers to bypass intended access restrictions by leveraging group permissions for a file or directory.

CVE-2014-5386
Published: 2014-12-28
The mcrypt_create_iv function in hphp/runtime/ext/mcrypt/ext_mcrypt.cpp in Facebook HipHop Virtual Machine (HHVM) before 3.3.0 does not seed the random number generator, which makes it easier for remote attackers to defeat cryptographic protection mechanisms by leveraging the use of a single initial...

CVE-2014-6123
Published: 2014-12-28
IBM Rational AppScan Source 8.0 through 8.0.0.2 and 8.5 through 8.5.0.1 and Security AppScan Source 8.6 through 8.6.0.2, 8.7 through 8.7.0.1, 8.8, 9.0 through 9.0.0.1, and 9.0.1 allow local users to obtain sensitive credential information by reading installation logs.

CVE-2014-6160
Published: 2014-12-28
IBM WebSphere Service Registry and Repository (WSRR) 8.5 before 8.5.0.1, when Chrome and WebSEAL are used, does not properly process ServiceRegistryDashboard logout actions, which allows remote attackers to bypass intended access restrictions by leveraging an unattended workstation.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.