Data-Only Attacks Are Easier Than You Think (2024)

Research Authors: Brian Johannesmeyer, Herbert Bos, Cristiano Giuffrida, and Asia Slowinska
Shepherded by: Rik Farrow
Published via: USENIX Security 2024

Core Thesis: While data-only attacks—exploits that leave a program's control flow untouched—were once dismissed as too complex or specialized to be a real-world threat, new automation tools prove they are surprisingly accessible.

---

The Landscape of Memory Safety

Imagine you are a security researcher who has discovered a bug allowing you to overwrite data within a target application. This is a frequent occurrence in the industry. In fact, major tech giants report a staggering percentage of their security vulnerabilities are memory safety issues:

The Evolution of the Exploit

Historically, weaponizing such a bug was a straightforward process of control-flow hijacking. An attacker would:

1. Overwrite code pointers.
2. Redirect the program to execute a malicious payload.

However, this is no longer the easy path. Due to decades of defensive engineering, modern systems employ several mitigations:

• DEP (Data Execution Prevention)
• CFI (Control-Flow Integrity)
• CPI (Control-Flow Policy)

These defenses make it incredibly difficult to force a program to execute code it wasn't designed to run.

---

A New Paradigm: Data-Only Attacks

Since diverting the control flow is now often infeasible, researchers are focusing on a different strategy: Data-Only Attacks.

In this scenario, the attacker does not change what the program does (the functions called, the system calls invoked), but rather the data the program uses while performing those intended actions.

Introducing "Einstein"

The authors have developed a tool called Einstein to challenge the assumption that these attacks are too niche or complex.

Einstein's goals include:

• Automating the generation of data-only exploits.
• Scaling the process for various applications.
• [y] Proving that low-effort attackers can execute these attacks.

---

Case Study: The Web Server Exploit

To illustrate the danger, consider a classic data-only attack on a web server.

1. Normal Operation

At startup, the server initializes a variable called cgi_bin_path to define where external programs are located.

• Initial Value: cgi_bin_path = "/usr/local/server/cgi-bin"
• Available Tool: A script called sort_script used to organize numbers.

The Benign Workflow:

1. Request: Client sends POST sort-script with data 2 1 3.
2. Concatenation: The server calculates the path: $\text{Path} = \text{cgi\_bin\_path} + \text{request\_path}$ $\text{Path} = \text{"/usr/local/server/cgi-bin"} + \text{"/sort-script"}$
3. Execution: The server calls execve("/usr/local/server/cgi-bin/sort-script", "2 1 3").
4. Response: The server returns 1 2 3.

2. The Malicious Workflow

Now, assume the attacker uses a memory safety bug (like a buffer overflow or use-after-free) to overwrite the cgi_bin_path variable.

The Attack Steps:

1. Corruption: The attacker changes cgi_bin_path to "/bin".
2. Request: The client sends a POST /sh request with the body touch /tmp/attacker-was-here.
3. Concatenation: $\text{Path} = \text{"/bin"} + \text{"/sh"}$
4. Execution: The server invokes the system shell: execve("/bin/sh", "touch /tmp/attacker-was-here").

Key Takeaway

In this attack, the server never executed unauthorized code. It performed its intended task (concatenating a path and calling execve), but it did so using malicious data. The attack effectively modified the arguments of a legitimate system call to achieve arbitrary code execution.

---

Summary of Findings

The research demonstrates that the barrier to entry for data-only attacks is much lower than previously believed. By automating the discovery and weaponization of these vulnerabilities, Einstein signals to software vendors that they must rethink their mitigation strategies to protect not just the flow of the program, but the integrity of the data that drives it.

Author Profiles: