Grand Theft Auto V exploit assigned CVE number due to partial RCE | Hacker News Reader

Grand Theft Auto V exploit assigned CVE number due to partial RCE

cve.mitre.org

62 pointsblackhole39 comments

These games have tens of millions of lines of code (often building on top of the older components). They are also written in memory unsafe C++, by developers focused on features and rapid sales, to users that look forward to new features not better security.

I won’t be surprised at all if they are filled with vulnerabilities.

https://www.gamedeveloper.com/programming/dirty-game-develop...

Look at "(s)elf-exploitation"

Uhhh, GTA V has been known for bad security for a long time. Streamers can't even play the game without a VPN or they get their IP leaked. Single-player games can (could, maybe still can? I am unsure of the current state of the game) get hacked and be messed with by hackers. This goes far beyond just "they used C++." This shows a great lack of caring for security in general from Rockstar, not just another thing that you can use to prove to yourself that "C++ is dangerous!"

I feel like I'm missing something here, but: the references are two support forum threads and a reddit thread, both of which link back to the referenced twitter thread? Is there any actual confirmation that this RCE exists? What does "partial RCE" even mean?

It really appears that this CVE was issued based on that super vague twitter thread.

RCE: remote code execution

CVE #: Common Vulnerabilities and Exposures number, assigned by the MITRE Corporation

I'm surprised more exploits aren't being found in games, they're usually thrown together as quickly as possible.

Ordinarily there's no reason why you would "attack" the game, so things only get found if a significant community arises for the game which would benefit, e.g. speed running Mario 64 is a thing, so figuring out weird details of the engine is crucial to the best possible times in categories which allow you to break the game to win.

For a Remote Code Execution bug like this it only makes sense if it's a popular multiplayer game, so that there are enough targets to be worth attacking, for long enough after release that you can identify a bug and figure out how to abuse it.

GTA V is like a decade old at this point, there a very few games with that sort of longevity, we're talking Minecraft, WoW, big hits rather than the average video game.

Video games being connected to the internet 24/7 are quickly becoming the norm. I am convinced there is a treasure trove of exploits created by the gaming industry just waiting to be found.

IIRC it's unsafe to play multiplayer in past releases of Call of Duty, even if fully-patched, because the games have a plethora of unpatched exploits (used on Xbox 360 to create modded lobbies), and I'm guessing the game's P2P nature makes it easier to find a client in your lobby to exploit.

The general recommendation is to install a community patch but I'd rather not run it at all, to be honest. I'd say "play in a VM" but I'm sure anti-cheat wouldn't like that.

Little reason to attack the game? How about knocking your enemies offline? Or getting their game or real money? Or recruit them for your DoS botnet? Because that’s what an RCE allows you to do…

Suppose it takes you six months to figure out an RCE for PowerWash Simulator. Yay, if you can find another player you can really pwn them now. Wait, how will you find a player to victimise? Nobody was looking for multiplayer PowerWash Simulator a month after it came out, let alone six months.

GTA V has been around for ten years but still has a huge player base and that's what makes this practical.

I assume most of the reverse engineering being done on games is with an eye to developing cheats rather than attacking players.

If you are exploiting the games it's easy to make money by selling cheats in the game, probably keeps people from looking for crypto ransom payoffs as much

GTA V has averaged >100k concurrent players on steam for the last 3 years, so a RCE has a lot of potential targets ripe for exploitation.

It only needs to make it into a mod-menu to get wide, unsuspecting distribution.

For those curious, mod menus are what "hackers" use to exploit the gameplay for fun. Script-kiddies are a good analog in history. They're often just kids who googled GTA hacks and installed from the first page they thought looked cool. They'll be prime targets for distribution.

Interestingly enough, it seems like some of these "mod menus" have already patched the exploit. Having one of these is almost a requirement for playing GTA Online these days, purely for the defensive features they offer against other cheaters. It's still a mess and requires trust (or a VM).

Just like script-kiddies back in the day, the easiest vector of attack is to distribute infected “hacking” tools

FWIW,

> CVE-2023-24059

What other video games have had CVE's?

Fairly recently Dark Souls 3 had a pretty bad one: https://nvd.nist.gov/vuln/detail/CVE-2021-34170

They took the online servers offline in January and to their credit they patched a 6 year old game and brought the servers back in September.

Factorio had a CVE that allowed RCE in multiplayer servers: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1161...

Not game specific, but I'll put this here: https://portswigger.net/daily-swig/valve-belatedly-fixes-ste...

Source Engine CVE-2021-30481

There's actually been a lot more of these that don't get CVEs It's one of the reasons I prefer to game in a VM with heavy network filtering and egress only through VPN

There is little to no care from game developers about security, games with actively exploitable RCEs (see pretty much the whole CoD franchise) are just allowed to stay up on Steam

Gamers are also kinda dumb and oblivious to RATs etc which doesn't help

How do you game in a VM? A lot of my game time includes flight simulators with many external peripherals.

Not gonna lie and pretend I know how it works but qemu is capable of passing USB devices into VMs while they are connected and visible to the host kernel, and this works perfectly for me for joysticks, steering wheels and other shit

For mouse and keyboard I just use the evdev forwarding thing where you press both ctrl keys to swap between host and guest

external peripherals is probably the easy part, given that usb passthrough almost always "just works" in my experience. The bigger problem is getting GPU passthrough working.

This is the biggest obstacle you're going to face:

https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF

With AMD cards it's relatively easy if you're willing to install two cards and have one of them just sit there doing nothing when you're not using the VM. It's also possible to use just one card and detach it from the host system, pass it to the VM, and then reattach back to the host system when you're done playing, although I spent multiple days on this and never got it working. YMMV, it was 2-3 years ago, the driver support may have improved.

With nvidia it ranges from difficult to impossible.

The only good working solution I found (other than PCIe passthrough or specialized GPU virtualization) is VMware stuff (with better success on Windows [as a host]), because their DirectX virtualization is top-notch. Years ago I did some random testing of my Steam library and got close to native performance.

Obviously, it means you can't use DLSS, RT, or any other GPU-specific features, but their DirectX virtualization supports up to DX12.

How do you play any game with anti-cheat in a VM?

Depends on the game. The answer for me is I'm not really interested in flavour of the month online shooter games so it's never been an issue but I know plenty of people who are and just continue to modify their VM until it's not detected - it's always gonna be something you can do to hide from the AC

Which anti-cheat would be triggered by running in a VM? I thought VAC worked by detecting runtime patching of .dll files.

VAC has a number of other triggers too but doesn't care about VMs in particular. I think everyone and their dog is an expert in not tripping VAC at this point

It's mostly those annoying ACs with kernel modules like EAC, BattlEye, ESEA etc. that do anti VM in an attempt to prevent cheat devs from 1. debugging the AC without at least a little effort and 2. having a clean OS but reading guest RAM from the host to avoid the anticheat entirely

Naive and trusting is probably a fairer characterization. They aren't nor should they need to be security experts, the company who distributed the code should be more responsible, and more controversialy I think they should also be more culpable. We are past the startup friendly wild west stage of software technology, we know better and should expect better.

Call of Duty before 2015, CVE-2018-20817 and CVE-2018-10718, another RCE too.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2081...

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1071...

If I recall correctly, the log4j exploit was first (publicly) discovered affecting Minecraft.

Just had a quick look at Luigi Auriemma's website[1] to see if he had any CVEs listed - he found a ton of interesting bugs in video games - I used to follow his work closely when I was running game servers as they often could end up impacting us & figured if anyone had some it'd be him, but surprisingly don't see any listed!

1. https://aluigi.altervista.org/index.htm

CVE-2022-47949

A bunch of first-party Nintendo Switch, Wii U, and 3DS games had a buffer overflow bug in a shared netcode library ("enl") which can be exploited by a remote attacker just by connecting to them in online play.

Affected titles included Mario Kart 7, Mario Kart 8, Mario Kart 8 Deluxe, Splatoon, Splatoon 2, Splatoon 3, ARMS, Super Mario Maker 2, and Nintendo Switch Sports. (The Wii U games remain unpatched.)

I heard EVE Online had server-side RCE exploits many years ago, not sure if it got a CVE though. I expect all games have some sort of security bug, even the completely offline ones get speedruns that exploit memory bugs to win faster.

My favorite EVE Online issue isn't a RCE/CVE, but rather just a general fuckup, where they, in an update, accidentally deleted the Windows boot.ini file off people's computers, rendering them unable to boot. https://www.eveonline.com/news/view/about-the-boot.ini-issue

Reply on news.ycombinator.com