> Data-only attacks, those that do not affect a program’s control flow, have long been considered too sophisticated and niche to pose a practical threat.
Leveraging user data to get malicious behavior is the basis of interpreter eval injection (php, js, perl, shell calls, SQL ...). These attacks are like 50 years old. What do I miss?
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.
miellaby · · focus · HN ↗
Leveraging user data to get malicious behavior is the basis of interpreter eval injection (php, js, perl, shell calls, SQL ...). These attacks are like 50 years old. What do I miss?
mtud · · focus · HN ↗
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.