A pair of Maltese vulnerability researchers have revealed a security hole in the game Battlefield: Play4Free from digital games giant EA.
The vulnerability takes advantage of the fact that different versions of Windows deal in different ways with erroneous input to the system function used to start new processes.
It's also a timely reminder to programmers that compatibility across many years' worth of operating system versions can come with an unexpected cost.
I shan't repeat the entire exploit (you should read the authors' original paper for that), but the jiggery-pokery goes something like this:
1. Tell the game's browser plugin to use the built-in "Game Updater" feature.
2. Trick the Game Updater into thinking it is connecting to one of a small list of official, trusted servers.
3. Send the Game Updater to a bogus updater site instead.
4. Instruct it to use TFTP to download and run a reverse shell program instead of a real update.
A reverse shell is a program that runs CMD.EXE, the Windows command prompt, on the victim's computer. The reverse shell then connects the command prompt's input and output to a network socket, not to the local keyboard and screen. This network socket is itself connected to a remote server specified by the attacker. So, when CMD.EXE starts and the network connection is made, the command prompt appears on the attacker's screen, not the victim's.
It's called "reverse" because the network connection is sneakily made outwards from the victim to the remote attacker, unlike a legitimate login, which is usually made inwards. Many firewalls don't regulate outbound connections as strictly as inbound ones, which are often prohibited altogether.
It's called a "shell" because that's the traditional Unix name for a command prompt.
The devious part of the security bypass here is the trickery in step 2.
The Game Updater has its own allowlisting feature which is supposed to restrict updates to a small set of websites. (The authors list just ten different names.)
But the allowlisting check is based upon a command line passed from the game's browser plugin to the Game Updater component via the Windows system function CreateProcessW().
And that's where the authors spotted an anomaly.
Windows itself limits the CreateProcessW() command line to a rather old-school 32 kilocharacters.
But the Windows documentation doesn't actually define what happens if your lpCommandLine string is too long; it says only that:
The maximum length of this string is 32,768 characters, including the Unicode terminating null character.
According to the authors of the vulnerability paper, only Windows Vista and later actually treat overly-long command lines as erroneous.
On Windows XP and Server 2003 (but you don't play online games from the server room, do you?), a superlong command line is quietly pruned back to fit into the limit.
Modifying the user's input and then processing it without notification is almost always the wrong thing to do.
If there is something wrong with your input, it should not be trusted and that fact should be reported.
So, on Windows XP, the attackers were able to bypass the allowlist check by tricking the calling process into padding out the command line so that the hostname part ended up more than 32,768 characters along in memory.
The browser plugin then faithfully reported the attacker's dodgy hostname, blissfully ignorant that the next process in the chain would never see the offending data.
The wrong hostname would be checked against the allowlist and would falsely pass the checks.
Note that if you don't play Battlefield: Play4Free, or you aren't running Windows XP, you aren't at risk here.
Let's call that 40% of one million people, a population that could make quite a handy botnet if the worst came to the worst.
So, if you are an XP-based Battlefield: Play4Free player, be sure to keep your eyes open for an update from EA!