Data-only attacks are easier than you think (2024)
usenix.org49 points by segfaultbuserr 5 hours ago
49 points by segfaultbuserr 5 hours ago
I'm missing a critical part of the explanation.
If "the server has a memory safety bug that allows a malicious client to overflow some buffer and overwrite, for instance, the contents of the cgi_bin_path variable", then why is this a data-only attack? Instill need to overflow a buffer the "traditional" way.
Data-only attacks are somewhat low-hanging fruit. Classical static analysis could already find them before AI got this strong, and LLMs make identification even easier. But the real threat is risk buried in business logic, especially abuse of normal business logic. Take e-commerce refund abuse. Bug hunters would not even call it a risk, yet fraud rings have arbitraged millions off this kind of logic. And because the logic is legitimate business logic, it is very hard to detect.
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.)
> Data-only attacks ... have long been considered too sophisticated and niche to pose a practical threat.
I thought the whole point of fuzzing was an example of finding data-only attacks.
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 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.
Add assertions to your code. Voila, your run-of-the-mill fuzzer can now hunt for arbitrary problems with your program by turning them into crashes.
When fuzzing C programs, I usually also add undefined-behaviour sanitizers and friends, in the mode where they crash when you run into the kinds of UB they can detect.
Again, the point of a data-only attack is that you replace, say, a string with another valid string, and take control of program logic that way. For example, imagine a program that uses `system(LS_CMD_STR)`, where that LS_CMD_STR is some kind of constant holding the value "ls -lah". If an attacker can corrupt program memory in such a way that it overwrites that value with "rm / -f", no amount of assertions will trigger on this, but the program will do something much worse than expected.
> The attack effectively modifies only the arguments of the execve syscall
I feel this checklist of shell-tools [0] is relevant, although the focus is more on how setuid is dangerous because you might not know the fancier arguments someone could supply.
> GTFOBins is a curated list of Unix-like executables that can be used to bypass local security restrictions in misconfigured systems.
This showed me that taint analysis is kind of slept on. Maybe we should invest in better tooling that allows us to reverse engineer with taint analysis easier. Do we think it is a UI problem? Of course over tainting is a thing, but maybe we can make it work with better UI.
Is that really the name for it? It sounds revolting
Can’t we just use prim and proper terms like provenance
"Provenance" tracks where data came from, but "taint" tracks where unsafe data can flow. It's a uhh not so sexy term, but it is the industry standard term.
It’s been a fair few years since I got to write some new Perl but I’m fairly sure you could use Perl -T which meant any variables passed into the program (typically from cgi) would be tainted until you safely extracted the contents (via a regex for example)
The word itself is getting on for a thousand years old, originally solely in the sense of colour dyes, similar to “stain”, but over time this was adopted to be “to corrupt” in a more figurative sense, I suspect the same root for taint and stain, with taint more indisputable and harder to remove perhaps.
Seems appropriate to use in computing.
The main meaning of taint is contamination. Not really a revolting term to me. Maybe you associate it with some of its other meanings and that’s why you find it revolting.
I'm positively surprised that their tool is not yet another LLM wrapper.
The quality of research (and by extent HN submissions) has really plummeted since LLMs have become marginally useful
(2024) in title/article date already spoils that, this article comes from BC/AC era boundary, so the tool itself must've been written in BC era. LLMs wouldn't be useful for any such thing for another year.
(BC and AC are obviously Before and After ChatGPT.)