Going on a bit of a tangent:

'Classic' non-AI fuzzers like AFL are still insanely useful and powerful, as are static analysis tools.

LLMs make all of these much, much easier to use. The other night, before I went to bed I told Kimi to go and fuzz filesystem code in the latest Linux kernel. I woke up to 26 crashes with reproducers and fixes. I'm still busy reviewing and upstreaming them. (Some have already landed.)

I still remember me and my friends on club live finding that the games you could just submit the scores for and get free xbox stuff, and then doing some research online years later we found the entire thing was setup by employees to abuse themselves with plausible deniability.

Club live lost msft millions of dollars by itself.

> And because the logic is legitimate business logic, it is very hard to detect.

Hard to detect at n=1, yes. But larger scale - are you assuming that no Accounting or Sales managers are watching the returns ratios, nobody in Shipping is minding carrier delivery failure metrics, and nobody in Returns is raising alarms about the bricks they're receiving?

I think of “data-only” as weird shorthand for “app-specific exploit primitives.”

An example I’ve seen somewhere is if a buffer overflow lets you change the value of another variable, but not directly control the instruction pointer. The exploit developer then has to figure out a way to turn their very constrained primitive into something useful, versus having access to a more powerful and generic primitive (stack return pointer, write-what-where, etc).

The example in the post is, basically, command injection, but it requires you to manipulate the app-specific state into a vulnerable state.

Computing is a huge subject, and there are many branches. For context, one branch, which I call "memory corruption studies", ever since the 1990s, is almost an entire research discipline with its own standing in infosec. As a result, entire OS concepts were invented to mitigate them (there even exists entire operating systems nearly dedicated to this this, such as OpenBSD and HardenedBSD), CPU hardware was literally modified to help mitigating them, new complier code generators were invented to mitigate them. Thousands of PhD degrees were awarded based studies on them. The research arm of every major tech firm has teams dedicated to them. There are infosec companies dedicated to this single subject.

In this context, practical data-only attacks as reported by this paper are the holy grail in this field.

As an outsider critic, you may say it's a side-effect of C/C++. If you use dynamic programming languages, this issue doesn't exist in your universe because there's no fundamental difference between code and data. But in another parallel universe of systems programming, it's a huge subject. Both the Morris worm and the publication of the article Smashing the Stack for Fun and Profit in Phrack were regarded by many as the milestones of hacker culture and canonical models of hacking, all the exploitation and mitigation studies that followed it were partially motivated by new hackers who wanted to "advance the field of hacking", so any advancement would be considered significant by a hacker. This is Hacker News, and I thought most people would understand this background. But apparently many developers are application-focused nowadays and hack in different universes, and it's not the case.

Most languages do not provide direct eval.

Corrupting program memory via malicious input data is known as a code-execution attack, not a data-only attack. The fuzzed program usually crashes because its executable code or the control flow got overwritten directly by the input, or indirectly by the program code itself when it tries to process bad data. An exploit involves injecting external code, or overwriting memory addresses (like a virtual table or a stack return address) to override the original logic flow to do something else.

A data-only attack would be an attack that reuses the original logic by only corrupting data inputs (such as a flag or a file path), without overwriting code or overriding the logic. W^X, stack canary, or CFI won't work in these cases since no code is tampered by the attacker. In almost ever talk about compiler mitigations, you always hear a passing-by mention of data-only attacks - before the speaker immediately dismisses them as an academic curiosity when the software industry is still facing a flood of stack smashing and ROP attacks.

The boundaries are a _little bit_ vague of course. Traditional attacks transition from "data" (the buffer) to a reality where all control is handed to the attacker (ROP, traditional executable stack pivots, etc.)

The attacker controls what's executed, and stitches side-effects together to achieve the desired attack. This also starts with "data" but ends with "instructions of the attacker's choosing doing what the attacker wants".

In a data-flow attack (which _still_ has some characteristics of the former), the attacker does _not_ have the ability to pick-and-choose what gets executed, even in the final stages of their attack. They _still_ need to overflow the buffer, and put some other data in some other registers, but their attack _never_ gets to the point where they pick the next instruction.

Likely, at the end of the exploit, arbitrary code execution or privilege escalation has been unlocked. But the exploit chain itself doesn't go through a stage of arbitrary execution (either through ROP, or executable stack). That's how I like to distinguish anyway.

Yes, the author uses specialized terminology which is easy to misunderstand. They automate DEP compliant transition from buffer overflow to RCE.