Recent searches
Search options
@godotengine@mastodon.gamedev.placeA malware loader, “GodLoader,” has been found exploiting the Godot runtime. This highlights the importance of only downloading software from trusted sources.
Full details: https://godotengine.org/article/statement-on-godloader-malware-loader/
@godotengine thanks for responding to this topic. I started a discussion about potential learnings from this in the forum post about it.
I'd love to see constructive discussion about this.
https://forum.godotengine.org/t/statement-on-godloader-malware-loader/93096
@feyter @godotengine Yes, a bad actor can use game jams to distribute malware. This problem cannot be solved thru arbitrary restrictions on Godot APIs, because those restrictions can easily be circumvented by using literally any other compiler, interpreter, or virtual machine.
A better solution would be to only play jam games in sandboxed environments (e.g. the browser).
@feyter @godotengine The risk of running code from untrusted sources will always be on you and on nobody else.
By the by, game jam games would be a horrible strategy for distributing malware.
@ratsnakegames @godotengine yes your right... Anyone can disable this restrictions by just editing the sources.
There is literally no possibility to disable this unless the OS disabled those features.
@godotengine Okay, I read that entire CPR report. From what I understand the big issue they have is that one can replace the .pck file of a game with malicious code. How is that different from running any suspicious executable off the internet? You can swap out files in *any* program to run malicious code.
Their conclusion of "everyone using Godot programs is potentially under attack" is insane. Anyone downloading anything off the internet is potentially under attack. Or am I missing something?
@godotengine Reading more closely, I guess their issue is also due to the fact that Godot can easily run console commands without any antivirus detecting it, but I guess that's a consequence of Godot just not being popular for running viruses.
@popcar2 @godotengine "GDScript is good for writing viruses because it is not popular for writing viruses, and thus is under the radar for antivirus software" sounds like a problem that is going to solve itself really quick.
@popcar2 @godotengine Their reasoning for saying that everybody using a Godot game is potentially at risk is that mods or similar can inject malicious code into a legitimate game. Which is a somewhat legitimate concern - but seems fairly theoretical to me for the vast majority of Godot games.
@ratsnakegames It's not different from saying someone could swap out your exe with a hacked one though, or swap out any of the files needed such as DLLs with malicious ones. If someone tampered with your file system, it's pretty much over. The report is pretty good and detailed but I don't agree that all games are potentially at risk.
@popcar2 Yeah, I absolutely agree.
I think you could also bundle a python interpreter, e. g. cpython with gdextension or rustpython and execute mailicious files. I guess you could also transpile source files before executing with an interpreter so gdscript support for malware scanners won't solve obfuscated code detection.
@HugeGameArtGD @popcar2 Virus scanners are bad at their job and that problem is kinda unsolvable. It's not really Godot's fault that they are garbage, and it's not Godot's fault if people put too much trust in them, either.
@popcar2 @godotengine There's a very long history of 'security' companies putting out panic pieces like this that essentially boil down to "the thing that is designed to run code, can also run malicious code if you download that" despite it not being a remotely new technique. It's a marketing tactic, trying to market themselves as "the company that found the new thing".
The only real 'insight' here is "this file type can contain executable code". Which isn't *useless* information, but also not really deserving of any more mention than a line on its Wikipedia page or, in this case, a warning on mod portals...
@godotengine@mastodon.gamedev.place @popcar2@mastodon.gamedev.place "Anyone downloading anything off the internet is potentially under attack."
Say it louder for the people in the back!!!
The fact that programs can access everything in userspace is (in my opinion) a ginormous security risk that we all just...live with, for some reason
... so ... someone wrote a virus with Godot?
I feel like this is a "nothing burger" ... Unreal or Unity3D or ... TensorFlow all have the same vulnerability, but, Godot doesn't have a legal department ...
@godotengine Damn, took threat actors long enough.
I've long held a pet theory that writing malware using Godot would give a threat actor a fairly good return on investment even when comparing other engines. That said, I don't think this is Godot's fault; IMO it is still difficult to safely run untrusted games and Windows still lacks serious sandboxing capabilities that are available for all users. On Linux you can at least use something like firejail or bubblewrap or Bottles… and even those options feel somewhat lacking or dauting for the average user.
Most Godot games out there cannot be run on W10 Windows Sandbox due to requiring Vulkan or OpenGL (this is the "anti-sandbox technique" Checkpoint Research talks about, and for the average malware sandbox I'd say this applies with any game engine), although this was fixed in Godot 4.3 with the addition of DirectX support. With Windows Sandbox being IMO the most user-friendly way to run untrusted Windows application, this makes it more difficult for an end user to safely run any untrusted Godot game.
Plus, you got a fully-fledged scripting engine out of the box that cannot be introspected by AMSI on Windows (not that it does a lot on red team scenarios anyway) and the engine is open source and single-executable so it's easy to add new capabilities at the C++ level and break existing reversing tools, with everything being compiled to a huge executable that makes Ghidra sweat (and gamedevs especially pre-4.0 can often end up shipping custom versions of the engine with added extensions, so you cannot just do a similarity analysis and discard executables that deviate too much from upstream without getting some significant false positives).
While encouraging gamedevs to lean towards web exports, I've also seen a lot of indie devs out there be frustrated with them in most game engines for various reasons, and now there seems to be an gamedev culture of "please download the game if you experience performance issues", setting the end user expectative and making the issue worse.
All in all, this is more of a systemic issue; the state of cybersecurity on gaming just sucks.
@godotengine In comparison to other engines:
- With Unity, you either have dotnet assemblies (which can be easily reverse-engineered using existing tools and could be easily fingerprinted and triaged against known-good hashes) or IL2CPP binaries (which are clearly delimited from the rest of the code and for which there's already tooling to uncover symbols and whatnot). Some games may also come with custom scripting runtimes, but I'd say these can be automatically flagged for further analysis in most cases.
- Unreal does share similar issues as Godot in this regard, though (including source code access, which last time I checked you could have for free even if the engine is not open-source). But I recall Unreal being a complete pain in the arse to export for platforms other than Windows, and it just being less accessible in general, especially at lower levels.
In both cases, games for both engines do at least work reliably on Windows Sandbox (albeit with levels of performance varying from "alright" to "PowerPoint presentation").
@godotengine This is a defender's problem with software frameworks in general, by the way; piggybacking off a new but somewhat established software framework is always an easy, low-cost way to make fully-undetectable malware. Game engines are just especially problematic in this regard due to how difficult it is to sandbox applications that require graphics acceleration.
@godotengine sounds more accurate to say a malware loader has been written that uses the Godot runtime. As currently worded, your toot sounds like the loader exploits a flaw in the runtime.
@godotengine Is it just for exported games, or does it also apply to asset packs and Godot demos?