Valve accused of ignoring existing RCE vulnerability in Source games for 2 years

This is a common problem in other parts of the software industry, but Valve is missing a piece of the solution.

The typical problem at software companies is that developers are incentivized only to write code for new features that will land them promotions and look good on their resume--but bugfixes and security work is not part of that.

Management can counteract this with top-down initiatives. Programs like "fix-it week" or teams dedicated to security with different incentives in place. For example, Google suffers from the "promotion-oriented programming" about as badly as any other company, but they manage to take security seriously.

Valve has "flat hierarchy", which goes in quotes because the hierarchy isn't really flat, it's just hidden. Because the hierarchy is hidden, it's harder to address large-scale problems like institutional priorities... because there are fewer people to delegate large-scale problems to.

Bots have long been designed to account for these types of checks by having scheduled hours and jittered breaks. Private messages and name mentions can alert the bot owner so they can respond manually. I've even seen bots that will pipe private messages to an IRC channel so that any number of restricted people can respond to the messages. It's been a long time since I've worked with game bots so I'm sure they're even more advanced now.

> ...make it well known that they're installing...

Many vendors originally hid the fact until they started receiving community backlash about it. For example, Riot with Vanguard originally hid*[0] that it was running 24/7, and also hid the fact that it blocked drivers, until people noticed and complained about it. Many games, PUBG Lite and Genshin Impact in recent memory, also do not reveal this to the user.

[0]: https://gameriv.com/vanguard-adds-a-system-tray-icon-to-give... *: I'm aware there was a blog post about it, but blog post about it != clear, upfront warning on install about behavior

> ...made by vendors that actively care about the security of their products...

Here's some fun, all involving anti-cheats:

- Using xhunter1.sys (XIGNCODE3) for an LPE: https://x86.re/blog/xigncode3-xhunter1.sys-lpe/ (still used in some MMOs!)

- Using capcom.sys (rootkit shipped with Street Fighter V) to write a rootkit: https://www.fuzzysecurity.com/tutorials/28.html

- Using mhyprot2.sys (from Genshin Impact) to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot (still exploitable, AFAIK!)

- Using BEDaisy.sys (BattlEye - shipped in Rainbow Six: Siege, Fortnite, etc) for handle elevation: https://back.engineering/21/08/2020/

In addition, you still need to trust the vendor (duh!). Some of them are essentially RATs, like BattlEye - it loads shellcode from the server that runs in BEService as NT/SYSTEM, and they can target code pushes by IP/ingame ID/etc. Reverse engineering the anti-cheat itself is not enough to trust it; it can change its behavior as it sees fit. They can even choose to specifically target you and steal your files, and there's a very high chance you'll never find out about it.

> ...and are trivially easy to remove once they're no longer needed.

Depends on how you define "trivially easy" - for eg. with Riot Vanguard, it installs/uninstalls separately from Valorant so you need to remember that separately. Some other ones, like xhunter*.sys install silently and aren't easy to uninstall at all unless you go delete files in System32. Others like EasyAntiCheat/BattlEye (last I used it, been years since I've touched them) need special uninstaller .exes that are included with the game, but are not registered with Windows or don't run automatically when uninstalling the game.

Genshin Impact's anti-cheat is not completely secure: you can use it to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot

Mirror repo after the original author took the repo down, but still exploitable AFAIK.

Theoretically - and vice-versa.

Depends on what the avenue of exploit you're worried about is. You can disable BIOS flashing from the OS in the BIOS, but that might still be theoretically vulnerable to, say, compromising the Intel ME environment and flashing from there; a rootkit loaded in SMM could hang around until the machine is cold power cycled (and theoretically compromise the bootloader(s) to load itself and then chainload the "real" bootloader every boot); if you want to get really invasive, you could theoretically start flashing various microcontrollers attached to the system (say, a USB flash drive, or your HDD/SSD controller) to do malicious things.

These get increasingly unlikely (and unreliable, without knowing and targeting the specific hardware you're using) as your attacker model includes less resources, but not impossible. Intel ME code execution, BIOS and SMM rootkits, malicious USB flash drive firmware and HDD firmware have all been demonstrated (I haven't seen malicious SSD firmware, but there's nothing theoretically stopping it other than the controller doing a lot more on them), and a couple have even been found in the wild.