mgaldys4
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.
|
> eru
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.)
|
> > billypilgrim
Similar use case here! Combining AI with fuzzers
is so powerful, especially for creating a special
fuzzing harness, or generating seeds for hard to
reach code. That was taking hours/days and was
frustratingly boring work before. Unfortunately
the Codex models refuse a lot for me, I'm mostly
using the cheapest models because they refuse the
least, have you found Kimi to be a good
alternative? Any other you tested that you can
recommend? Thinking of switching.
|
> > > eru
So Codex with Daybreak Blue refuses less. You
need to join OpenAI's cybersecurity program.
But it seems to be pretty simple: I just told
them that I do some Linux kernel work for fun,
but that codex refuses anything that touches C
and the kernel.I've also tried DeepSeek and
now Mimo. DeepSeek was really quite useful
before the price increase, because I didn't
care too much about burning a lot of tokens.
But it was less useful since, especially since
my timezone here in Singapore is the same as
in China, so my waking and working hours have
a lot of overlap with their peak pricing.
However, it's gotten a bit cheaper
effectively, because their new flash model is
supposedly as good as the old pro model.Which
cheap models are you using (especially those
that refuse less)?So far I've only really used
Mimo to drive Sashiko, which is a kernel
review tool. I haven't used it for actually
writing code.Kimi is pretty decent overall.
But I haven't given it really hard work.
Running a fuzzer is pretty simple, and so's
the other stuff I asked it so far.
|
> > Foobar8568
At work, I am arguing with tech leads that they
should sanitize user inputs for a public facing
chatbot.I want to cry.
|
> > > eru
Oh, I'm doing the fuzzing for fun.But yeah,
you can't trust user inputs!
|
> > wavemode
> (Some have already landed.)Do you have links to
some of these?
|
> > > eru
Accepted by maintainers so far:In
mainline:ext4, xattr cache:
https://git.kernel.org/pub/scm/linux/kernel/gi
t/torvalds/lin...ocfs2, cluster accounting:
https://git.kernel.org/pub/scm/linux/kernel/gi
t/torvalds/lin...Taken into Jan Kara's
filesystem tree this week, all isofs:An
out-of-bounds read in the multi-extent
directory walk:
https://lore.kernel.org/all/20260923153220.777
907-1-matthias...A hang in a fix Jan had just
written, which he is folding into it:
https://lore.kernel.org/all/20260923153134.771
632-1-matthias...A bug Jan fixed himself after
my report:
https://git.kernel.org/pub/scm/linux/kernel/gi
t/jack/linux-f...Sashiko, the LLM patch
reviewer that now comments on kernel mailing
lists, merged a fix of mine:
https://github.com/sashiko-dev/sashiko/pull/55
6 (a patch that contained one of its prompt
placeholders as text had it replaced).Not
accepted yet, but I think interesting:libata,
reviewed by the maintainer but not applied
yet: a faulty ATAPI device could make the
kernel write past its sense buffer.
https://lore.kernel.org/all/20260922182655.242
3663-1-matthia...e2fsck, the repair tool,
could deadlock on some corrupt images and hang
forever. Reviewed by Darrick Wong.
https://lore.kernel.org/all/20260922110435.152
8332-1-matthia...ntfs: a crafted image makes
mount hang forever, because the mount waits on
a lock its own read already holds. One of the
maintainers asked for a wider fix, which I am
testing.
https://lore.kernel.org/all/20260922153931.197
6405-1-matthia...Sashiko was reviewing ext4
patches against a tree from 2020:
https://github.com/sashiko-dev/sashiko/issues/
559, fix in
https://github.com/sashiko-dev/sashiko/pull/56
0, plus a one-line MAINTAINERS patch naming
the ext4 branch, which Jan acked:
https://lore.kernel.org/all/20260923101749.350
5886-1-matthia...Not posted yet, still being
reviewed on my side:ntfs: writing to a
compressed file on a volume whose free space
is fragmented silently overwrote clusters
belonging to other files. write() reported
success; the damage only showed after a
remount.ntfs: reads of a damaged file could
return zeros for data that is on disk, and
writes to it could be dropped.Sashiko: on its
Claude, Vertex and Gemini backends, a
connection that drops mid-response is treated
as a permanent error rather than retried.The
rest, mostly more ntfs, are still in review or
on my desk. Not all of these came from that
first night; the ext4 and ocfs2 ones are
older.I also have a lot of bcachefs
contributions, but that's because I'm actively
using that filesystem on my desktop; instead
of a pure fuzzing run.
|
> > elzbardico
It is more than LLMs are faster using those tools,
than they are finding more errors by themselves
analysing the code.
|
> > > eru
These tools find different errors, I'd
say?Fuzzers execute, which has different
failure modes that having an LLM do informal
reasoning on the code. (I haven't played
enough with static analysis to say anything
insightful about how they compare with
LLM.)The Linux kernel is a really big piece of
software. Using a fuzzer to point you at an
interesting (and potentially dodgy) piece of
code is a good start. Often once you found the
first problem, you or your LLM can read around
and find more problems.
|
> hilariously
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.
|
> > pixl97
Lol, heh, how long before we find AI is setting up
hidden doors like this to extract money from
software they make via external methods.
|
> bell-cot
> 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?
|
miellaby
> 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?
|
> segfaultbuserr
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.
|
> mtud
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.
|
> saagarjha
Most languages do not provide direct eval.
|
Terr_
> The attack effectively modifies only the arguments of
the execve syscallI 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.[0]
https://gtfobins.org/
|
gumby
> 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.
|
> segfaultbuserr
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.
|
> > eru
> 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.
|
> > > tsimionescu
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.
|
> > > > segfaultbuserr
In microcontroller programming, redundant
data, checksumming and token-passing are
sometimes used to mitigate CPU
malfunctions due to electromagnetic
interference (microcontrollers are often
used as "programmable logic", so there's
no hard layering between hardware and
software, layering violation is made on
purpose). If anything looks wrong, you
trigger an assertion failure and reset the
chip via the watchdog timer. For example,
when you pass LS_CMD_STR, you would also
pass the name of the caller and the CRC32
checksum of the string as arguments, and
the function on the receiving side should
validate them.So I think adding assertion
is definitely a way to discover data-only
attacks in fuzzing, or even as a partial
mitigation of these attacks. It's just
stack canary for variables and strings
(but as the paper authors said, complete
mitigation can be impractical).
|
> > > pixl97
It's not bad data, that's kind of the point of
it.
|
> > GoblinSlayer
TFA says memory corruption is a data-only attack,
because it just overwrites data in memory.
|
> > > segfaultbuserr
It depends on what you overwrite. If you
overwrite a CPU instruction or a function
pointer that followed the buffer, it's a
code-execution attack. If you overwrite a data
variable that followed the buffer, it's a
data-only attack. I said nearly all
conventional fuzzing found code-execution
attacks, not data-only attacks. Isn't that
clear? The former method is considered common,
well-studied, with defenses, the latter method
is considered rare, niche, and defenseless.
|
> > > > GoblinSlayer
Conventional fuzzing tries to overwrite
executable code? I thought crashes are
usually due to dereference of a corrupted
pointer leading to unmapped memory.
|
probably_wrong
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.
|
> SCHiM
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.
|
> GoblinSlayer
Yes, the author uses specialized terminology which is
easy to misunderstand. They automate DEP compliant
transition from buffer overflow to RCE.
|
joa-
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.
|
> setr
Is that really the name for it? It sounds
revoltingCan't we just use prim and proper terms like
provenance
|
> > ill-ion
"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.
|
> > > hdgvhicv
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.
|
> > QuantumNomad_
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.
|
> > > stackghost
"Taint analysis" is certainly evocative.
|
> chuckadams
Taint analysis won't help against memory safety
vulnerabilities that directly scribble over untainted
data to make it malicious. You need something like a
secure enclave to prevent that kind of tampering.
|
lemmegetthis
Is this article saying that this AI tool has found 944 NEW
unpatched exploits in nginx, and a comparable number in
other commonly used server software? Total 944
Table 2: Confirmed exploits for nginx.
|
> segfaultbuserr
First, there is no "AI", the author showed even a
simple static analysis as proposed by them was
sufficient to find data-only attacks, in contrary to
the common belief that you need heavily customized
exploits per application for this kind of attacks.
This is the whole point of the research.Next, I
believe they found 944 available "data-only gadgets"
usable by a pre-existing memory corruption bug. You
still need to find a memory corruption bug first to
use them, in the same sense that you need to hunt for
ROP gadgets to get arbitrary code execution on a W^X
system.
|
burgerone
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
|
> TeMPOraL
(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.)
|
> > pixl97
The last 2 years has been a very long eon.
|
sylware
Well, with all the enshitified complex file formats out
there, I bet this is a "piece of cake" (for the people of
the field with good tooling) to find exploits in the state
management of code dealing with them. And very high
computer languages/specialized script languages won't
protect anything as those are "logic errors". I think
"closing" state machines on such complex file formats is
just pointless, better design new file formats from the
ground up, but this time with a much stronger focus on
robustness (keep that state machine as small and simple as
possible and super rigorously well defined, and I mean
like maths maniacs). And it is hard: because the purpose
of the file format must come AFTER the robustness, namely
tough compromise on the purpose itself may have to be
done.
|