Security with Godot Sandbox

[fwsGonzo]

Security in Godot Sandbox

Godot Sandbox will eventually be safe to use. That time is in the future, and the way it will be communicated is by adding a SECURITY.md readme file that explicitly enumerates the guarantees and non-guarantees of the extension.

What is Godot Sandbox

First off, let's define the Godot Sandbox. What will it be? It's going to be a memory- and system- safe protection layer that prevents anyone from reaching the host system. At most, people will be able to modify and trash the game. That's fine, and we can call that an antagonistic mod. What's not OK is executing code outside of Godot, modifying the file system or in any way reading out sensitive information.

What is GDScript

Today, people write GDScript to create games and occasionally to let people modify a game. GDScript can be evaluated as a string like JavaScript and it is the most integrated solution in Godot. It is not, however, safe. Try pasting -9223372036854775808 / -1 anywhere in a GDScript window on amd64:

handle_crash: Program crashed with signal 8

So, GDScript is not a safe scripting language by any stretch of the imagination. Instead we have to reduce the surface area greatly, and do what we can to completely avoid GDScript interaction.

The current implementation

The current implementation may be safe, and it has a few architectural ideas:

• Variants are always translated in and out of the guest
  • Even though Variants are slow, they are the only communication primitive for VM function calls
• Objects and Nodes must be seen in order to be operable
  • After a call ends, all knowledge of nodes and objects evaporate
  • All deletion/freeing is deferred to the next frame
  • It is possible to make arbitrary calls on Nodes and Objects, which is a great thing to support, but breaks the sandbox
  • Only certain global Objects are accessible
• Only in/out Variants, Objects and Nodes are accessible
  • A few operations like get/set, call and a few node-manipulation functions are implemented as system calls
  • The current API has a low surface area, which perhaps can be audited

Creating malicious trees

The sandbox gives the user access to node manipulation, including adding children. As such, one can create a hierarchy of nodes of ones own choosing. It is very likely possible to create a tree in such a way that an exploit can happen. A classic example is some kind of self-growing subtree bomb that more or less locks the computer up until oom-killer is invoked.

The sandbox places limits on objects and nodes that can be active, but ultimately the limit will likely continually be increased in order to not constrain modders. We may as well say that the limit will tend to what the game can bear.

Execution timeouts

Execution timeout is possibly impossible to rein in. There are too many operations that can take a long time, and as such, trying to limit the sandbox to a certain time-frame without signal interruption is hopeless. Infinite loops are taken care of by instruction counting, and many costly system calls have penalties that increase the counter suitably. Nevertheless, there are many operations in Godot that modders must have access to, that would be able to keep the system hanging forever.

In short, we can only say that execution timeout is present, but not a guarantee. Nor is it always wanted. People will just close the game if it's not working as intended. No harm, no foul.

Timing gadgets

It is likely easy to find timing gadgets, so I am not sure if lowering the granularity of the usual timers are going to do anything but make a side-channel attack demo take longer to make. The sandbox is supposed to be speculation-safe, but we cannot guarantee anything outside of it, and there is too much sandbox-reachable code in Godot. I suspect timing attacks will be possible, with enough time. This is a topic that I have very little knowledge of, so take all this with a grain of salt. Should you, dear reader, have any knowledge, please let me know what you think.

Future

The safety aspect will remain exploratory for a while.

The current strategy is to double-down on a reduced interface that uses node-operations and vararg calls directly out to Godot. So, the host/guest boundary is very small, but the access to Godot is very wide currently. Limitations may need to be placed on calls especially.

[fwsGonzo]

The Godot Sandbox has recently gained a new restriction system as well as some hardening against self-tampering (sandbox trying to unrestrict itself through the APIs).