Godot SecOps state?

In sum:

A server and a client.
How much safe and atack resistant is the binary?

For the client, there is literature about lets say, cheat engine atacks?

And for the server, that exposes a api. How much trouble to get that endpoint injected with arbitrary GDScript, ergo, getting acess to full content of runtime memory?

Safety is to be implementation dependent, of course, but as a general bias, if one is basing critical data on a godot server, how much of a atack point does one became?

Is godot safe? Or “just as safe as any other executable”?

Godot doesn’t have much security hardening. You need to be careful what you expose and validate requests come from a valid source by yourself.
In itself Godot should be reasonably safe as it does not expose anything by default, but it’s not like specifically hardened against attacks.

1 Like

A few more points specifically about clients and servers:

The server really depends a lot on your implementation as by default it shouldn’t expose anything. I personally also always would put it behind a firewall or similar to limit the attack surface (not only of the engine, but the whole system).

As for client hacks, this is a very hard problem to solve. Even large games can’t entirely prevent this. Anti-cheat software is quite expense and in most cases people find a way to work around them. So big games instead (or additionally) do server side validation. Basically you will want an authoritative server that checks if the actions done by the client are valid. In addition to that, you can work together with one of the anti cheat software providers. Keep in mind though, everything client-side can easily be changed by an attacker, so you shouldn’t only rely on that. Always validate on the server side, it’s the only place you have 100% control of.

1 Like

So… As as safe as anything else?

But the server, does it have exploits? DIrect exploits.

What i am most concerned is one being able to run a :
bytes_to_var_with_objects()
with the arbitrary code they need, on any exposed endpoint.

None of the endpoints even have, lets say, the bytes_to_var.

For now, there is no privilege escalation bug found on godot??

Privilege escalation in regards to running other programs? Or what kind of privilege escalation?

Objects should never be decoded with default settings, except if you manually enable this or use this method by yourself. Godot’s multiplayer API will not decode objects by default.

I don’t know of any privilege escalation bugs in Godot, but from context I assume you are asking about remote code execution, not privilege escalation. There was one in the past (CVE-2019-10069) but it was fixed for Godot 3.2 already, so if you use a somewhat recent version (2020 or newer) you should be safe.

2 Likes

Yes, i said that on a bad generic way of doing-something-that-class-of-agent-should-not-do.
Indeed, that is what i was looking for, in the context of server security.

This does not seen to be very discussed either…
There should be a bug-bounty program on something like this.

If one can make a endpoint somehow decode objects, its possible to dump any state of the engine, and even the system via OS.execute.

The question is to make a “safe” conection decode a object. And this is the scope i am trying to understand. Overflows, and so on, there may be a miriad of aprouchs that can open a slit and enable script modification.

Are this miriad exhausted and comproved to be inexistent?

As I said before, Godot is not specifically hardened. I am not aware of any external security reviews of the codebase either. All I can do here is repeat what was stated before: The networking code should by default not allow for any RCE, and the one vulnerability that became known was promptly fixed afterwards. I’m not aware of any new RCE vulnerabilities that were discovered after that.

If you need a more definitive answer, you will either need to review the source code by yourself or find someone who can do this for you (probably paid).

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.