0

Apologies in advance if this is the wrong SE site for this topic, though it should be a fairly appropriate match.

I am building a video game where one of the features available to users will be online multiplayer. I will be releasing the server software for free (and open source) with the hope that users will be able to run their own modifiable servers for their communities.

Servers may utilize "vanilla" resources freely, however some may opt to add their own resources such as textures and models. What I would like to accomplish is to enable clients to (with explicit user action) download the required assets.

To add a further layer of complexity, some of these assets are available for download publicly, while some are proprietary and only available through the server.

My main concern is the mitigation of malicious files through the distribution software. However, my "saving grace" may be that all the files that are distributed will be .png, .txt, .xml, .yml, and .mdl, and all will be usable in their existing forms without modification.

The files will not be pushed to the client, but rather the client will pull. This will eliminate any issues with the server having access to the client's filesystem, which could really do harm.

Now, for the question part of this:

Besides a large disclaimer letting the user know that it's their problem if something happens, where should my concerns be placed regarding the safety and validity of files?

All communications to and from the server will be encrypted, likely using something similar to the Signal protocol. Additionally, when a server admin uploads a file, I will have the server generate a hash which should allow the client software to verify that the file was not modified in transit, though nothing more.

A mass majority of the files transmitted will be .txt files, which by themselves should hold no inherent danger (to my understanding). Additionally, none of the files are executed. Code on the client's machine will parse the files and discard anything that is not the right format.

I understand that not every concern can be addressed here because the topic is fairly large, though any pointers on any potential issues or anything else to just be generally aware of will be appreciated.

1
  • No need for "..." and the end of your sentences.
    – peterh
    Commented Jan 16, 2017 at 15:16

1 Answer 1

-1

Some stuff:

Part 1/4, the server resources:

To add a further layer of complexity, some of these assets are available for download publicly, while some are proprietary and only available through the server.

And how do you prevent that a client downloads it and then takes the file and distributes it freely? Not at all, right. You need to give up on that plan, there's no effective protection.


Part 2/4, the connection:

Signal protocol and some plain hashes of the transmitted data? Don't roll your own... I'm not sure about Signal, but use eg. TLS and you have everything. Encryption, integrity, authenticity...


Part 3/4, the end points:

Files, ie. byte blobs, don't do damage. Errors in file-reading programs do. And yes, even images and txt files ... it doesn't matter what kind of file: If the program has an error, certain file contents can lead to malicious actions.

What this means for you? Feeding an image to the OS to display it is alright. If the OS has an error, it's neither your fault nor you're in a position to fix it. Same for third-party-libs etc. (altough reporting bugs should be one of your tasks).
But your program is as important. The bug doesn't need to be in the grapics lib, OS etc. . Even if your program just reads the image from the net and passes it on, there could be a bug there (buffer overflow...) which can lead to an exploit.
I can't really tell you not to make bugs, because everyone does, but be aware that each of your own code lines has the potential to become an infection for all users.

And do not, never, not for any reason, trust the other side of the network and/or any previously saved files. Don't rely in the client that the other side is your own server, and vice-versa. Check everything that needs to be checked. Same for saved files: if you load them, run the same checks as for newly received content from the network.


Part 4/4, cheaters:

Again, as server, do not trust the client. This includes information like "I'm client number X" (can be faked, introduce a secure authentication system), "My highscore is XYZ" (haha. Save it server-side and always calculate changes there, without any client input), "I just shot enemy Foo and that killed him" (calculate server-side if there is an enemy foo, what weapon you have, what damage it can do, what health Foo had, where you pointed your weapon, if there's an obstacle between you and foo, if your last shot was too recent to shoot again, etc.etc.), and so on.


The client always lies to the server. And the server to the clients too. All files are evil. And all players are evil too. Keep that in mind, and 90% of the security work is done.

1
  • For topic 1, I think you misunderstood. What I had meant was that some resources are available from download sites distributed across the web while some are developed specifically for the server (hence "proprietary"). Whether the client takes the proprietary files, or the publicly available files for that matter, and distributes them on their own time is not a concern to me. 2/4, See Signal Protocol 4/4 has no relevance. Client asks server if there are required files. If yes, client goes and gets them.
    – Foxtrek_64
    Commented Jan 17, 2017 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .