[bakugo]

Almost every single online game out there that relies on players connecting to each other instead of only a central server is vulnerable to these types of exploits, it's often just a question of finding them.

Every once in a while I feel like playing one of the older Call of Duty games on my steam library again, but then I remember that they all have known unfixed RCE exploits.

[armchairhacker]

This is why you rewrite it in Rust \s

But seriously, one of the reasons games should maybe be less C++ and more memory-safe languages, if not Rust then languages like C# or JavaScript. And maybe incorporate formal methods into game-dev. The code which handles server responses should be sufficiently isolated from any of the unsafe code (e.g. rendering), so that you can ideally prove (or non-ideally, at least be very confident) that a server response cannot cause arbitrary code execution.

Maybe it still won't be sufficient against state actors, but it would mean that you can reliably play an old game like you can reliably view a webpage.

I would not be surprised if COD and GTA have remote-code exploits, though.

[mopsi]

Microsoft Flight Simulator[1] is a really interesting example, because running code from third parties has been the norm for decades. Custom code for things like airplane instruments was distributed in DLL modules that had full Windows API access (file system, networking, etc) while the game was running. It's obviously a huge security risk.

So for the new version of Flight Simulator, they divided it into core game engine and "content packages" that fill the rest (airplanes, landscape, missions, other assets). Packages get loaded into a virtual file tree[2]. Packages may contain custom code, usually compiled from C++ to WASM, but the code is executed in isolated containers and it does not have access to the underlying file system. It only sees contents of its local package within the virtual file system.

As a result, the shiny airplane you bought from some online marketplace can't read your documents folder and send its contents to remote servers anymore. It remains an issue with many other games where third-party modifications ship as unrestricted DLLs, even on authoritative-looking platforms like Steam Workshop. For example, a pathfinding fix for Command & Conquer on Steam is just a DLL swap[3] - this should make security-concious people very uneasy.

[1] https://docs.flightsimulator.com/html/Programming_Tools/WASM...

[2] https://docs.flightsimulator.com/html/Developer_Mode/Menus/T...

[3] https://steamcommunity.com/sharedfiles/filedetails/?id=21371...

[int_19h]

This kind of thing was fairly common historically. For example, Quake 2 mods were DLL / .so files, depending on the platform, and modding was more common than not in multiplayer. Or the just-released Mount & Blade 2: Bannerlord, which is written in C# and runs on the full-featured .NET Framework on Windows - its mods are managed assemblies, naturally, and they run under full trust.

(And then you go meta and write a mod that compiles and loads source code at runtime: https://www.nexusmods.com/mountandblade2bannerlord/mods/1651)

[doober]

"Maybe it still won't be sufficient against state actors, but it would mean that you can reliably play an old game like you can reliably view a webpage."

https://www.cvedetails.com/product/15031/Google-Chrome.html?...

oh and muh rust magic safety https://github.com/Qwaz/rust-cve