I’ve recently been looking into the ConfigFile class in Godot, in particular seeing if I could make a system to load them without worrying about Arbitrary Code Execution (or ACE for short). I’ve worked together a relatively simple system that seems to work, but I’m not an expert, so there might be some issues. Basically it looks at the cfg file and if it contains certain keywords that could be used for code execution, it rejects the file entirely.
Here’s the function:
# This functions attempts to verify that no objects or scripts are being loaded before loading the cfg file.
func load_cfg(path: String) -> ConfigFile:
var cfg_str = FileAccess.get_file_as_string(path)
if cfg_str.containsn("object"):
push_error("Config File at path %s contains an object that may be malicious. Halting load operation." % path)
return null
if cfg_str.containsn("resource"):
push_error("Config File at path %s contains a resource that may be malicious. Halting load operation." % path)
return null
if cfg_str.containsn("script"):
push_error("Config File at path %s contains a script or object that may be malicious. Halting load operation." % path)
return null
var cfg = ConfigFile.new()
cfg.load(path)
return cfg
If anyone can find a way to bypass this I would greatly appreciate it if you could tell me. I’ve done some basic testing but I’m not exactly an expert when it comes to Godot Object serialization. If there’s a better method that would also be great to know!
Also, feel free to use this in your own projects, I’m happy to help anyone prevent accidental code execution.
ConfigFiles don’t run code when loading, you shouldn’t have to worry about it loading scripts, objects, or resources, is there something that brought this concern to you? Resources can run code, you should be careful using ResourceLoader.load on untrusted files.
Config files can contain objects (and by extension, resources), which can run code. And as for ResourceLoader.load, yeah, the default resource loader is completely insecure. As far as I can tell the ConfigFile system is probably pretty similar to var_to_str and str_to_var, which do object serialization. While you are correct that they don’t run any code on their own, they absolutely can contain objects, scripts, etc. That’s why I’ve made this thing, to be able to use config files for modding, save files, etc.
Could you demonstrate that? Your demo project doesn’t contain a malicious example, only an example of a false-positive. I would be very interested to see ACE through ConfigFile, or even str_to_var
Okay I’ve updated the project demo with a new danger.cfg file. It’s a basic print message if it loads, but the scanner catches it.
I’m not super familiar with str_to_var but I do know that it can parse objects so it can very much be used to execute code, since the _init function runs before any sort of post-load scan can delete the script.
Wild, it really does it. JSON has parameters for allowing objects which is disabled by default, that really really should be added to ConfigFile too. Granted it’s a little rarer to send malicious settings files than save files, and config files are usually easier to read/vet than JSON, still a oversight in my opinion.