6
\$\begingroup\$

Let's say I have both a game and a modding system for it. The modding system loads DLL files containing custom features and allows mod creators to override certain functions to change game mechanics. This is all well and good until some mod creator decides to put a keylogger or a virus in one of those DLL files. What can be done to prevent this problem? Is there any way to allow a high level of customisability in a modding system while still maintaining a strong level of security for the end user?

\$\endgroup\$
  • 2
    \$\begingroup\$ Is taking the mods in DLL format a requirement? Or would you be open to exposing your modding functionality in other ways that don't necessarily entail running arbitrary native code? \$\endgroup\$ – DMGregory Nov 2 '17 at 1:10
  • \$\begingroup\$ @DMGregory How else could you do this? \$\endgroup\$ – Gigas Nov 2 '17 at 11:05
  • 1
    \$\begingroup\$ That's s job for an answer, but as just one example, you could load a text or bytecode script file that's run in a virtual machine inside your game, with access to only the methods you want to expose, so you can have a strong guarantee that it's not making arbitrary system calls or vandalizing the player's machine. \$\endgroup\$ – DMGregory Nov 2 '17 at 12:00
  • \$\begingroup\$ @Gigas I would argue that how else you might do it is a related, but separate question. I totally agree that there are other, possibly better (or at least more secure) alternatives. If that's what you want, I encourage you to ask a new question. \$\endgroup\$ – Pikalek Nov 2 '17 at 14:35
  • 2
    \$\begingroup\$ @Pikalek The question is about how to prevent, so how else you do it definitely is within the scope of that question. The question itself doesn't specify that you need to use dll files, just that OP is doing that now. recommend against separation of the questions. \$\endgroup\$ – user106170 Nov 2 '17 at 14:39
5
\$\begingroup\$

You cannot prevent it (in situations which are equivalent to running arbitrary native code supplied by others).

You can:

  • curate the mods
  • screen submissions with a scanner
  • restrict your API as much as possible
  • select a language that is safety oriented
  • sandbox foreign code

All of these increase safety to varying degrees. But none of them are a guarantee.

\$\endgroup\$
  • \$\begingroup\$ Is there any way to curate DLL files if the source code of the mod is not provided? \$\endgroup\$ – Gigas Nov 2 '17 at 0:42
  • 2
    \$\begingroup\$ By curate, I was referring to a generic process by which files (of any type) are submitted for review & only made available upon approval. In that sense, you can curate most anything. The logistics of implementing such a plan vary. for instance, the approval process may be simple (ran it & it didn't crash) or complex (examining the binary for suspicious instructions). \$\endgroup\$ – Pikalek Nov 2 '17 at 1:26
  • \$\begingroup\$ With DLL files, points 3-4 are impossible and 5 is very difficult. DLL files contain compiled binary code. A DLL can do anything a windows executable can, include calling native windows API functionality. And they don't need to be written in the same programming language as the program which calls them. \$\endgroup\$ – Philipp Nov 4 '17 at 13:53
  • \$\begingroup\$ True, you cannot control the language selected by the user or the API provided by the OS. API restriction & language choice can make your own program more resistant to exploit by removing a few easy attack vectors. I'm not up on modern OS memory management to know if something like a buffer overflow in the DLL can be exploited by the DLL to access the memory space of the calling app, though. \$\endgroup\$ – Pikalek Nov 4 '17 at 20:51
2
\$\begingroup\$

As others have stated in the comments, the easiest way is to either embed an interpreter in your game (for example, Lua scripts are fast-ish, and there are a number of good implementations scattered across the web for various languages) or create a simple text parser and read files. For example, you could roll your own text format for simple scripts, embed lua for mire complex scripts and gui-related tasks, and load object definitions from JSON or XML.

For example, in my strategy game;

1.) Unit types are defined in xml - safe[1].

2.) GUI layout is defined in xml - safe.

3.) I use a custom parsed scripting language for simple events.

4.) Lua is used for gui interaction. I have removed the io, and os functions effectively rendering these scripts safe.

[1] - As others have stated, these approaches aren't necessarily "safe" just "safer" than including compiled dll's.

\$\endgroup\$
  • 3
    \$\begingroup\$ While those approaches seem safe if implemented correctly, you need to be weary of implementation errors. Programming languages like C/C++ without automatic bounds checking make it very easy to build bugs into parsers which allow arbitrary code execution. And disabling functionality in a programming language can be harder than it seems at first glance, as numerous vulnerabilities in the Java Applet technology for web browsers have shown in the past. \$\endgroup\$ – Philipp Nov 2 '17 at 16:58
  • 4
    \$\begingroup\$ I think "safe" always needs an asterisk. For instance, I could make a mistake in my XML parser logic that, say, assumes a text string won't be longer than X, or doesn't sanitize it for escape characters, leaving it vulnerable to a buffer overrun or "Bobby Tables" attack, where "safe" xml might be able to trigger behaviours I didn't deliberately expose. ;) Ooops, looks like Philipp and I were typing the same thing at the same time! Sorry for the double-up! \$\endgroup\$ – DMGregory Nov 2 '17 at 16:58
  • \$\begingroup\$ @Philipp Fair enough, I've edited the question slightly, though the xml approach is almost undoubtedly safer than including potentially-malicious native code :-) \$\endgroup\$ – JDSweetBeat Nov 2 '17 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.