> It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that.
Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions.
Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance.
> But what is the arbitrary data going to be?
An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.
It sounds like you picked option 1 then, which means you don't need to take control of the sandbox. "Create an image that put arbitrary bytes into the buffer that stores its decoded form." simplifies to just "Create an image." There is no vulnerability here. This is just image display happening in a normal way. It's something to keep an eye on but not important itself. You have to add a vulnerability to get a vulnerability.
The original problem of preventing image decoding exploits has been solved in this hypothetical.
> Your original request was: “If you've seen an exploit caused by a big pre-allocated array of untrusted RGBA data, please explain how.”
I asked that in a context of whether you can contain vulnerabilities in a sandbox. If something doesn't even require a vulnerability, then it doesn't fit.
Also please note the words "caused by". A few helper bytes sitting somewhere are not the cause.
> Which is exactly how exploit chains work.
> A single vulnerability usually doesn’t achieve something dangerous on its own. But remove it from the chain and you lose your exploit.
Being part of an exploit chain doesn't by itself make something qualify as a vulnerability. (Consider arbitrary gadgets already in the program. You can't remove all bytes.) And I've never seen "you can send it bytes" described as a vulnerability before. Not even if you know the bytes will be stored at the start of a page!
Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions.
Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance.
> But what is the arbitrary data going to be?
An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.