+44 (0)203 88 020 88

Menu

Search

Cyber Security News & Articles

 

Cyber Security
News & Articles

Trusted Cyber Security Experts
25+ Years Industry Experience
Ethical, Professional & Pragmatic

How Return-Oriented Programming exploits work

Return-Oriented Programming is a security exploit technique used by attackers to execute code on their target system.  By obtaining control of the call stack, the attacker can control the flow of existing trusted software running on the computer and manipulate it to their own ends.  New research published this month has demonstrated how SPECTRE style vulnerabilities can be leveraged with modern ROP techniques to create a new and powerful class of attack called BlindSide.

 

Stack Buffer Overflow Attacks

The call stack is a data structure that controls the execution flow of a computer program. It tracks the calling of subroutines and the exact position in the code where execution resumes after each subroutine completes.  A stack buffer overflow occurs when data is written to the stack which is longer than the length of the memory space allocated to the buffer – the result is that the adjacent memory space is overwritten.  Since that memory space will form part of the contiguous call stack, the contents of the stack has been changed which will result either in the program crashing (because the new contents make no sense) or the program flow changing because the new data can be interpreted as valid stack entries.

A number of technologies have been introduced to counter the threat of stack buffer overflow attacks, including:

  • Stack Canaries (placing a random integer value at a specific point on the call stack which is regularly validated – if the stack if overwritten this value will change allowing the program to self-terminate safely)
  • Data Execution Prevention (prevents the execution of code in memory spaces which should only contain data – like the call stack)

In response to these mitigations, new attack techniques were developed – the most powerful of which is Return-Oriented Programming.

Return-Oriented Programming

The first example of ROP was published in 1997 and focused on abusing the libc library which is present in most compiled C programs. Since the structure of the libc library is well known, it is possible to identify the memory address of every subroutine and craft a call stack buffer overflow that does not corrupt the call stack (causing a crash) but simply replaces the memory pointer with one that will invoke a libc subroutine (or chain of subroutines) selected by the attacker which then performs a function helpful to the attack.

This type of abuse of standard libraries was made much harder with the introduction of Address Space Layout Randomisation (ASLR) in 2002.  ASLR randomly arranges the address space positions of key data areas of a process so an attacker does not know which addresses to inject into the call stack in order to abuse libc or other known software libraries including the system Kernel. The introduction of ASLR and changes to many system libraries like libc that made it harder to abuse their functions spurred new research and in 2007 the Return-Oriented Programming technique was first demonstrated.

The Intel x86 architecture is dense – it has many different instructions and so any random set of bytes is likely to be interpretable as a valid sequence of x86 instructions.  It is possible, therefore, to search through a software binary file looking for specific machine code instructions (opcodes) that perform a useful function – the most interesting being the return instruction (0xC3) and then back-track to see if the preceding bytes form valid instructions that can be used.  These small snippets of instructions ending with a return instruction are known as ‘gadgets.’  Given a sufficiently large quantity of code (such as libc) there will be enough gadgets discovered to allow the creation of a Turing complete instruction set – meaning any desired function or program flow can be achieved. Tools such as ROPgadget automate the search for gadgets in software binaries.  Since the gadgets are discovered in a known binary (such as certain Linux distribution) there is some protection provided by ASLR in that the attacker needs to do some work in order to identify the memory location of the library which contains the gadgets they wish to exploit. However, once a single gadget or other identifiable data item has been located in memory the location of all the others can be inferred as ASLR does not alter the contents of software in memory – only the starting location for each library.

Blind Return-Oriented Programming attacks

Blind Return-Oriented Programming develops the ROP approach to allow software to be attacked sight unseen – without the need for the attacker to first harvest gadgets from their own copy of the software binary.  This extends the scope of ROP attacks to include proprietary closed-binary systems. The limitation is that the targeted software will crash many times during the attack and so it will only be effective against services which are configured to auto-restart (and the repeated crashing does not draw the attention of systems staff to investigate and identify the attack while it is underway).

Researchers at Stanford University in 2014 were able to remotely start a shell process on nginx + MySQL servers (with stack canaries and ASLR defences in place) in 20 minutes using a BROP exploit they developed called Braille.  Essentially, they repeatedly corrupted the return address of an exploitable function, forcing the program to return to every possible address in search of a libc target, while the server recovered from crashes by spawning a new process each time.

What is the BlindSide attack?

In September 2020 a team of European researchers published the results of their work attempting to exploit Spectre style speculative execution vulnerabilities present in the micro-architecture of modern CPUs combined with a BROP style attack.  By leveraging the speculative execution capabilities of modern CPU, the attackers are able to abandon calls that would otherwise result in a crash and so successfully use BROP techniques to identify useful gadgets to exploit without the disruptive and attention-grabbing crashes. As a result, they were able to target components that are not crash-resistance – such as the Linux kernel – and successfully retrieve the root password hash from memory.    The team posted a video of their proof of concept code running on a Linux device and obtaining root access.

The abstract of the BlindSide paper summarises the results succinctly:

To defeat ASLR or more advanced fine-grained and leakage-resistant code randomization schemes, modern software exploits rely on information disclosure to locate gadgets inside the victim’s code. In the absence of such info-leak vulnerabilities, attackers can still hack blind and derandomize the address space by repeatedly probing the victim’s memory while observing crash side effects, but doing so is only feasible for crash-resistant programs. However, high-value targets such as the Linux kernel are not crash-resistant. Moreover, the anomalously large number of crashes is often easily detectable.

In this paper, we show that the Spectre era enables an attacker armed with a single memory corruption vulnerability to hack blind without triggering any crashes. Using speculative execution for crash suppression allows the elevation of basic memory write vulnerabilities into powerful speculative probing primitives that leak through microarchitectural side effects. Such primitives can repeatedly probe victim memory and break strong randomization schemes without crashes and bypass all deployed mitigations against Spectre-like attacks.

Mitigations for BlindSide style attacks will need to be prepared by both hardware (CPU) and software (Operating System) vendors – there is nothing the Security Manager can do today in order to mitigate against these kinds of attacks.  However, there is a useful lesson here as noted by the BlindSide researchers: BROP style attacks have been well studied for many years and it is assumed they are understood – but by chaining or combining BROP attacks with the Spectre vulnerabilities new avenues of attack become available.

The attack surface of your network is always changing – even if you make no deliberate changes yourself. Every software patch changes the attack surface of your servers and each new research paper reveals previously hidden possible vulnerabilities.  So even for networks with low levels of change, it is important to maintain a regular tempo of testing and checking (through vulnerability scans and penetration tests) to ensure that new discoveries and vulnerabilities do not compromise systems you assumed are still secure today because they were shown to be secure six months ago.

 

 

 

Subscribe to our monthly newsletter today

If you’d like to stay up-to-date with the latest cyber security news and articles from our technical team, you can sign up to our monthly newsletter. 

We hate spam as much as you do, so we promise not to bombard you with emails. We’ll send you a single, curated email each month that contains all of our cyber security news and articles for that month.

Why Choose SecureTeam?

Customer Testimonials

“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”

Aim Ltd Chief Technology Officer (CTO)

"Within a very tight timescale, SecureTeam managed to deliver a highly professional service efficiently. The team helped the process with regular updates and escalation where necessary. Would highly recommend"

IoT Solutions Group Limited Chief Technology Officer (CTO) & Founder

“First class service as ever. We learn something new each year! Thank you to all your team.”

Royal Haskoning DHV Service Delivery Manager

“We’ve worked with SecureTeam for a few years to conduct our testing. The team make it easy to deal with them; they are attentive and explain detailed reports in a jargon-free way that allows the less technical people to understand. I wouldn’t work with anyone else for our cyber security.”

Capital Asset Management Head of Operations

“SecureTeam provided Derbyshire's Education Data Hub with an approachable and professional service to ensure our schools were able to successfully certify for Cyber Essentials. The team provided a smooth end-to-end service and were always on hand to offer advice when necessary.”

Derbyshire County Council Team Manager Education Data Hub

“A very efficient, professional, and friendly delivery of our testing and the results. You delivered exactly what we asked for in the timeframe we needed it, while maintaining quality and integrity. A great job, done well.”

AMX Solutions IT Project Officer

“We were very pleased with the work and report provided. It was easy to translate the provided details into some actionable tasks on our end so that was great. We always appreciate the ongoing support.”

Innovez Ltd Support Officer

Get in touch today

If you’d like to see how SecureTeam can take your cybersecurity posture to the next level, we’d love to hear from you, learn about your requirements and then send you a free quotation for our services.

Our customers love our fast-turnaround, “no-nonsense” quotations – not to mention that we hate high-pressure sales tactics as much as you do.

We know that every organisation is unique, so our detailed scoping process ensures that we provide you with an accurate quotation for our services, which we trust you’ll find highly competitive.

Get in touch with us today and a member of our team will be in touch to provide you with a quotation. 

0

No products in the basket.

No products in the basket.