UnrealScript security considerations

This article lists some basic security considerations concerning anything you create using UnrealScript.

If I prevent the client from clicking the wrong button, I'm safe, right?

an unsuspecting modder

Well, not really. The uncomfortable truth is, the client can do stuff the author can't predict. In fact, crackers (i.e. the evil kind of Hackers) have found many ways to make servers do things they would never done for regular players.

Kinds of exploits

All the evil things crackers may do to a game server can be categorized as follows:

Cheating

This involves all the annoying things to break the rules of the game, like wall hacks, speed hacks, aim bots, etc.

Denial of service

Anything that makes the game unplayable for technical reasons, for example hogging the server's CPU, causing network lag or simply crashing the server.

Taking control

The attacker breaches security measures to change game settings or make the server do things only the server administrator should be able to do.

Entry points

Attackers have different ways to achieve any of the above exploits:

Console commands and configuration settings

As simple as it may sound, but the game itself or any of the mods running on the server may make console commands or settings available to regular players that allow any of the above exploits. Of course that can be considered a serious bug in the game or mod and needs to be fixed. An example is a crash vulnerability in older versions of the Unreal Engine that involved invalid class names. If a client was able to make the server try and load such an invalid class, the server would crash, and there were many ways to do that.

Loading additional code to use existing code in unexpected ways

This is probably the most common way to activate cheats nowadays. The client runs some loader program or otherwise "injects" custom code into the game client, be it via a DLL file or an Unreal package file. In both cases the client gains access to new features, such as radars, aiming helps or even more powerful weapons.

Modifying existing code

Files that came with the game or belong to mods running on the server are modified in a way to unlock otherwise inaccessible features or to add custom code. This approach could be used to disable built-in features, such as no longer blinding the player after he was exposed to a flashbang explosion.

External tools

For some exploits it's not even necessary to run the game. As soon as the server provides other means of access, such as a web interface or some kind of query protocol, those can be used to trigger unwanted behavior.

Preventing exploits

So, how do you prevent malicious players from doing all these things, if you have so few control about what the client does? The answer is actually quite simple:

Do not trust the client. Ever!

Validate everything the client sends. "Client" in this case is not only the game client, but for other access methods (e.g. web interfaces) it includes the tools to access those (e.g. a web browser).

Game client and server communicate through replication, particularly the client uses replicated functions to send anything to the server. Under no circumstances let the client call functions directly through replication if they can cause any of the following things:

• perform expensive operations, such as iterating over all actors or loading irrelevant objects (causes lag due to CPU hogging)
• cause function calls to be replicated to all or many clients (causes lag due to increased network traffic)
• instantiate actors/objects (uses up memory and CPU)
• modify admin-only settings
• execute arbitrary console commands
• modify the URL options for the next map (danger of admin password override!)
• set game-relevant default or instance properties to arbitrary values

This list is likely incomplete, so apply common sense to figure out other potentially critical things. Whenever you create a function that is replicated to the server, ask yourself if a client could cause problems by calling it with special parameter values or simply by calling it extremely often. Do not rely on your own client code to prevent such things!

Also you must not only watch out for what the client may send back to the server, but what you simply leave handled by the client.

For instance you should make sure certain delays or important checks are not left in client-side code where they could be modified, If it would work and be more safe server-side or with proper replication.

Examples

A few examples that could have been avoided through better code design.

UT ZP "massmurder" cheat

This exploit was created based on the zero-ping InstaGib mod for UT. The ZP creators intended to eliminate ping problems in InstaGib games by moving hit detection from the server to the clients. Basically when the player fires, his client does not send the information "I fired" to the server. Instead it performs the firing logic and hit detection locally and tells the server "I hit player X", which causes that player to die. The massmurder cheat in essence told the server "I hit all players in view at once" - and the server believed it.

This is a good example why the server should never trust the client. ZP lacked even the simplest validations, like how quickly the shots were fired. Ideally a ZP-like mod should not only validate shot intervals, but also check hit plausibility, i.e. perform a server-side hit test, possibly taking ping into account.

UT200x cheat loading

UT2003 and UT2004 contain lots of configurable entry points that allow loading of custom code. Making things worse, Epic turned off the server feature that disallowed clients with unknown code packages loaded because some mods were badly coded and didn't unload on clients when switching servers. UTComp in its earlier versions was one of the most popular mods with such a bug. Later when the Anti TCC and SafeGame anti-cheat mods included checks to compensate the disabled security features of the game, people blamed the security mods, like they blamed UT2004 before. The UTComp bug was fixed eventually, but other mods remained buggy and there are probably still such mods around. The UT2004 feature to detect such problems has never been enabled again and the best solution still is to let anti-cheat mods perform expensive searches for unknown code.

TAM takeover vulnerability

The popular 3SPN mod is another example of careless code design related to server security. In its version 2.57 there was a bug that allowed attackers to take control of the entire server. The vulnerability was found and fixed in version 3, version 2.57 was patched separately.

UTComp takeover vulnerability

This is the latest findings in critical vulnerabilities exposed by a mod. The cause is the same as the TAM vulnerability: Careless code design. Unlike the TAM vulnerability, however, this one is a zero-day exploit. It was only found after it was actively abused to tamper with many UT2004 servers. It must have existed for a long time already and is not fixed yet. The exploit is know of being exploited since at least 2008-2009.

The TAM and UTComp exploits have the same cause, a replicated function for an admin feature without any plausibility check. Basically if the attacker writes custom code to call that function, the server will execute code that was never supposed to be called by non-admin clients.

Solution

This exploit can be suppressed by disabling UTComp built-in voting system. If the voting system was the only reason you use UTComp, then please remove(also delete the .u file!) UTComp completely as it consists of more exploits than this.