Wow, allowing remote execution of a bytecode language that directly operates on system resources is a bit terrifying. This can’t be the only Unity API that wasn’t designed to be secure when called by untrusted code from the internet.
Absolutely. The other exploit I wrote from two years ago that I alluded to in the post involved a vulnerability completely different component. That one abused a (presumably decades-old) heap overflow in the S3M tracker module format in the FMOD audio library built into Unity. I think there isn't nearly enough serious vulnerability research into games outside of cheater groups.
As a side note, that S3M vuln was a massive pain because the chain of responsibility was even longer. That's why I lost a good chunk of the writeup for that before it was safe to publish it.
That part about the Steam overlay is interesting. This stuff is over my head, but this makes it sound like Valve's implementation creates an unnecessary attack surface. Its also pretty lame that disabling the option for it has no effect on the exploit.
Personally, I think that part ended up being more interesting than the Unity bug itself purely because of the implications. A friend was able to abuse the xinput1_3 RWX region in particular to get code execution in a different game with only an arbitrary write primitive and no ASLR leaks. I wouldn't be surprised if this trick got abused for in-the-wild game RCE exploits like the Apex Legends one (though I have no way to verify that).
This is a really impressive find. And opens a big can of worms. I understand better now why Apple won't allow JIT compilers. Though i still think it's up to the user.