Security model

This page is an initial (disorganised, incomplete) attempt at an overview of the game's security risks and requirements.

This doesn't mean to imply anything about the state of the current alpha releases, which have had no attempt at security review and likely have many serious bugs. (Any known bugs will be fixed, and we'll try to avoid designing features that are likely to introduce many more, so we're not actively avoiding security and might be no worse than many other games, but we can't currently claim it wouldn't be trivial for someone to find exploitable bugs.)

By "security", this page mostly means things like code execution vulnerabilities (or other bugs that could potentially be exploited in that way), which can compromise a user's system outside of the game itself. Cheating and DOS attacks (e.g. resource exhaustion or triggering assertion failures) are assumed to be inevitable - they should be avoided when possible but are not critical.

Sources of untrusted data

We assume that all the executables and data files and configuration files provided with the game are trusted by users who choose to install it. Other sources of data are:

  • Multiplayer network communication - players connect to untrusted servers. Communication happens via ENet (over UDP). Packets are decoded by the engine code, then either handled directly by the server or deserialised into a JavaScript data object which is passed to the gameplay scripts. (Only simple data objects are handled - they can't include executable JS code.)
  • Other network communication - eventually this will likely include some kind of lobby server, probably using JSON-over-HTTP handled by the game's GUI scripts, with complex bidirectional communication. If an attacker hijacked the DNS or compromised the server, they could send malicious data to players. Currently there is only the opt-in feedback service, where the game uses libcurl to send a POST request and then simply checks the response status code, so malicious responses should be unable to cause harm.
  • Automatic updates - eventually we may want the game to offer to download and install updates automatically (at least on platforms without decent package management systems), so that multiplayer won't get fragmented by people with obsolete versions.
  • Manual downloading of third-party content:
    • Random map scripts.
    • Scenarios.
    • Content mods (adding new units, with textures and meshes and animations etc).
    • GUI mods (changing the game's interface).
    • Total/partial conversion mods (changing everything from content to GUI to gameplay scripts to default control configuration etc).
    • Saved games.
    • Replays.
  • Automatic download of third-party content - if you join a multiplayer game that uses content (especially maps) you don't already have, we probably want the game to automatically download it for convenience.

Scripting

The security of running untrusted scripts depends on two components:

  • The SpiderMonkey engine itself. (This has been designed specifically for running untrusted scripts (on the web), and has had a large amount of testing and continuous review, but a few of the post-release bugs listed here are vulnerabilities within SpiderMonkey.)
  • The environment exposed to scripts by the game engine. There are a few different environments (all strictly isolated from each other) for different usages:
    • GUI script environment. (Not designed for security at all - a load of error-prone functions are exposed, including e.g. Engine.Crash() which always crashes.)
    • Simulation script environment - used for gameplay scripts and scenario script triggers. (Designed in theory to be secure, only exposing safe functionality, but complex and likely quite buggy at the moment.)
    • Random map script environment - used for random map generation scripts. (Designed to be secure, exposing very little functionality.)
    • Network server decoding environment - used for serialising/deserialising scripted command data. (No functionality exposed at all, except for the basic logging and profiling functions that all scripts have access to.)

Future directions

Currently the main development focus is on gameplay functionality, and users of alpha-release software shouldn't be surprised if it has serious bugs, but the security issues ought to be addressed ideally before doing beta releases. Probably the most important things, in decreasing order, are:

  • Review and test all the engine code that receives and decodes network packets (probably including ENet itself), to avoid any possible buffer overflows or invalid state transitions etc, so that clients and servers can connect without trusting each other.
  • Make the simulation command-processing code filter commands, so that network players can't inject bogus data into the engine through invalid commands.
  • Review and test the random map scripting environment (and the associated C++/JS interface system), so that untrusted random maps can be safely executed. Then we could support automatic downloading of random maps.
  • Review and test the simulation script environment and all the features that are exposed to it, so that untrusted scenarios can be safely executed.
  • Give up trying to make the GUI environment secure - assume that people only install GUI mods from trusted sources.
Last modified 3 years ago Last modified on Apr 12, 2011 12:57:57 PM