What are the real world risks of opening ports for multiplayer games?

Question

We have a multi-user enterprise training application built using the Unity game engine and are discussing the security implications of adding a Windows Defender Firewall rule globally opening an application specific port for that application on the systems where it is run. Due to the architecture of the application the set of executable paths is not known at install time so we haven't figured out a better way to whitelist just the required port on just the executables we need than globally opening the required port.

The application is run under a non-admin account and is installed with an installer that doesn't currently require any elevated privileges. It doesn't do general disk IO, it only reads its own data files and writes out logs to hard coded locations. The systems the application runs on are not on the corporate domain and are not used for any other purpose (they should not have any sensitive data stored on them).

There is some concern about the security implications of globally opening a port. It seems to me that the real world risks are quite low. We can choose a port which is not used by any other applications or services running on the machine so the only real risk would be someone figuring out a successful remote privilege escalation attack on the application itself while it was running (a risk that is somewhat inherent to a multiplayer / multiuser game-type application). I may be missing some potential security implications here however. I'm interested to hear people's thoughts on how big a security issue this really is in practice.

Answer 1

The risk of opening a port is that the listening application can be exploited. This means that, for instance, if a Unity zero-day is found these systems would be at risk. Only half 6 months ago a remote code execution bug was found in the Unity Editor (CVE-2017-12939). Note this affected the editor, not the games created by it. New security bugs are discovered all the time, thus any application listening through an open port could potentially be attacked.

Make sure that the port is only opened for the specific application, to prevent the port from being open for other applications that you might install in the future.

If you're paranoid and want to reduce the risk, there are a few options.

Do you need a listening port?

If you build the application in a way that only the servers are listening and the clients initiate the connections, you don't need to open a port (unless you also have an outbound firewall on those clients). This also saves you the hassle of having to forward ports manually on NAT devices in your network.

Create a minimal priviledged user account for the application

You mentionioned that your application only needs read-only rights on a few files in a specific folder. you could create a new user account on the systems you install the application on, and give it priviledges to only that folder. If you do this, make sure the application is run using that user account. This means that if an attacker exploits the application, he will have more troubles to escalate priviledges. This however takes a lot of extra work and is only for the truely paranoid.

Answer 2

I agree with your analysis.

Starting from the top, opening a port means that arbitrary (potentially malicious) traffic can and will be routed to the process listening on that port. You are guaranteeing that this game will be the only thing that could ever be listening on that port.

We can choose a port which is not used by any other applications or services running on the machine

So the attack scope is the game application, as you point out:

the only real risk would be someone figuring out a successful remote privilege escalation attack on the application itself while it was running

So the question boils down to: how much do you trust a game application to be designed with security in mind, and properly handle all possible malformed inputs to that port? Personally, I would not trust that very much. @Snappie's answer confirms this.

Since we don't trust the application to be hardened, we need to treat it as "potentially compromised" and sandbox it appropriately. Ask yourself "if this box got totally pwned and was completely under the control of an attacker, what damage could it do?". It sounds like you're already thinking in the right direction, so yay, good job!

The systems the application runs on are not on the corporate domain and are not used for any other purpose (they should not have any sensitive data stored on them).