The timeline mentioned in the post displays a scary lack of professionalism from Valve. For a full RCE (with full chain required to even be acknowledged!), taking over a YEAR to fix it and then having an almost insultingly low payout for it does not fill me with confidence as a user. What makes this worse is that if it had been exploited, even just getting account takeovers would have been catastrophic, not even speaking of other fun stuff people can do with an RCE. Many csgo players have items of insane monetary value in their steam inventories, so getting account takeovers would've been a direct link to profitability with this exploit.
I'm very disappointed hearing this about such a reputable software maker.
I expect that many, if not most networked games have RCEs in them.
Security is not a priority. Priorities are performance and getting the thing out the door under constant crunch time with minimal cost and likely nobody hired specifically to handle this kind of security.
Performance usually means shortcuts everywhere, a mentality to avoid anything unnecessary in normal operation (like checks that values are within an expected range), and memory-unsafe languages.
Add various anti-cheats and you'll probably get an almost free escalation straight to the kernel too.
Also, lots of complexity, and often built-in scripting languages.
Edit: In this specific case, it was a series in logic bugs, in code that would generally not be considered super-sensitive and thus receive additional attention for a security review. To write secure software, every developer needs to be security aware, and a game company isn't the environment where you can expect that to happen.
Yes I think that this is actually very common and we just don't hear about it much.
Most of these online multiplayer games are implemented with heaps of unsafe c++, and due to the nature of the game, are constantly parsing inputs from the network, and from other clients. This is a recipe for disaster!
For this reason I will only run modern games in some sort of sandbox, ideally in a VM with GPU pass through, or maybe run them on a dedicated system that is only used for games.
Even in a VM, exploiting it would give access to the passed in GPU, and from there I'm not totally sure what is possible, so even this isn't perfect but it's quite a lot better than nothing.
Normally people are launching the game through the steam GUI under their regular uid, so CS:GO for example with this setup, can read and write to all of the data in ${HOME}. That's pretty scary!
Even running steam through flatpak doesn't give you much protection when sharing the X11 socket.
I think the most reasonable setup for the "average user" is to create a separate user account on their system that is dedicated to gaming. You can run graphical sessions for both users at the same time and switch between them via whatever method (i would just switch between multiple ttys). Users on Unix-like systems in theory should not be able to interfere with other users, or even harm the system so long as they can't escalate to root. It's important to realize that there are situations where an unpriv'd user can harm the system, like if there is a bug with sudo, or a kernel exploit! I think it's much better than the default though!
If only both of you guys knew that Valve has been working on CS2 for the past three years and no, it's not "10 people" it a lot lot more.
I agree it took them too long to fix these vulnerabilities but Valve is notorious for its schedules/timeline/insane delays. It's been a meme for years now.
