Security in games
While much has been said about the security failings of Windows, there is some burden on the application programmer to not put the user in a bad situation to begin with.
Perhaps the biggest violators of this contract are game programmers. They are a lazy breed when it comes to concerns ourside of gameplay. Many games require that the player run the game as Administrator. This isn’t a limit of Windows - this is due to stupid designs of many games, which do things like write player settings to the Program Files folder.
Now, I’m not flawless here. When we wrote Dead Man’s Hand we did the same stupid thing. Of course, our middleware, Unreal, did lots of silly things, like install itself to the root directory, and had certain problems with spaces in file names.
These might have been okay assumptions in the 1990 DOS era, but these days, you really should expect that companies who license middleware so widely, don’t force every licensee to fix all of the same security problems.
Now, the problem begins with the games requiring you to play as Administrator, but in order to run a dedicated game server, you need to log in. They might have some console program, or put an icon into your notification area, but the fact is, you need to be logged in as Administrator to run a dedicated server.
Think about that. Every one of the dedicated game servers based on popular games like Unreal or Quake, can be completely owned if they have the slightest buffer overrun. This includes servers run in datacenters.
Now, if these games were designed to run as services, without requiring Administrator privileges, then the servers are much more flexible and can be more secure. The changes to make this happen are trivial.
I’m not sure why we don’t demand more from our game makers. If there was an outcry from gamers about having to run as Administrator, things would be fixed pretty quickly.
Until then, we can just blame it on Windows. ![]()
We weren’t completely complacent on Dead Man’s Hand. We did do things like compile with SafeSEH and buffer overrun detection. We also rolled our own GameSpy code, and used the latest zlib, unlike many other developers. When a bunch of Unreal games were found to be exploitable in 2004, Dead Man’s Hand was not among those affected. Some of those games are still exploitable.
Still, I’d feel much better if you didn’t need to run as Administrator. In hindsight, I should have been more proactive about the issue. But, that was hardly Dead Man’s Hand’s biggest problem. One day, I’ll explain why you can’t install the game to the W: drive. ![]()
May 31st, 2005 at 10:05 am
omg…. I totally forgot about the W: drive thing! Surprised we haven’t heard at all about that yet.

Unfortunantly, one of the problems with licensing middleware, is that management quickly frowns on spending time “fixing” middleware problems - in their eyes, middleware engines are “perfect” to a large extent.
-mike
June 1st, 2005 at 12:12 pm
One of the ideas I have been batting around is that the middleware is at an interesting inflection point. The Quake 3 source should be released “soon” and it might be practical to for small companies to build on that base for legit game development.
Sure, it might be open source (depending on how you license from id), but many companies open source their gameplay code anyway.
Even today Q3 isn’t far behind the state of the art - I’ve said many times that the Unreal 2 engine was only a marginally better game engine (perhaps cleaner for the level designers…).
The upside is not starting from scratch. The downside is that you now need to keep up with the trends on your own - and this includes fixing the problem areas instead of assuming your licensor will fix them for you