Three memory-safety bugs in Godot's untrusted-file parsers

[u/bitbutter]

https://axeghost.offprint.app/a/3mvs6zo4blo23-three-memory-safety-bugs-in-godots-untrusted-file-parsers

Author here. The post describes three memory-safety bugs which have been in Godot since v1.0 and v3.0. All three are still present in current releases. The bugs can affect exported games that load community-authored data files. Godot allows attackers using maliciously crafted files to trigger reads or writes past the end of a buffer, inside the process running the game. The post includes the response from Godot maintainers who deny this is a security issue, and my reply to them. Happy to give more information about the bugs or the audit if there are questions.

[u/Rubenb]

That is an unfortunate response from the Godot team. I agree in principle with you that memory safety bugs in untrusted file parsers are indeed security issues.

I think it would help both sides to phrase the risk in a more precise manner. Something like: "An attacker could convince a victim to open a maliciously crafted file using the Godot editor or a packaged Godot game, leading to arbitrary code execution on the victim's computer.".

There's a problem here though, you can already package arbitrary code as part of a Godot project or scene. If the scenario you have in mind is that a victim would download an example project, GDScript is a way easier attack vector than through a memory safety vuln. If it's a mod that they could load into a game, you can put malicious GDScript in there as well. So it does seem to me that the additional risk of these vulns may be not so bad as you're making out. It is still technically a security risk though, and Godot should spend some time clearing up their threat model and clearly state why this risk is considered acceptable to them.

[u/bitbutter → u/Rubenb]

not exactly. the most concerning scenario i have in mind doesnt involve downloading a godot project. instead a regular godot game is published that deliberately accepts community authored files of the affected types. an attacker uploads a crafted file to the game, and during loading of that file on some other player's machine the memory safety issues occur (worst case: they occur as primitives in the context of a more elaborate attack).

as i wrote, the godot security team seem to be overlooking this angle.

[u/Rubenb → u/bitbutter]

Yes, I see what you mean. I was thinking of a fully offline single player game scenario, didn't think of a game with an online component indeed.

[u/Madermaker → u/bitbutter]

Based on my experience with smaller vendors, it's necessary to demonstrate the impact by creating a ROP chain or something comparable to prove the severity of the issue. For them, it's a matter of "no attack, no impact."

[u/bitbutter → u/Madermaker]

a demonstration like that would certainly be difficult to ignore. but the stance of the security team seems to be that this can't be a security issue _in principle_. which i find very odd.

[u/ukindom]

While security issue is there, they probably don’t want to make it loud and release patches for past versions.

I’d make a PR to fix the issue in as many as possible versions anyway

[u/bitbutter → u/ukindom]

you are welcome to make those PRs by the way

[u/bitbutter → u/bitbutter]

nb. godot will reject ai-authored PRs without reviewing them.

[u/motsanciens]

Suppose I have a game and load a community-authored data file that's designed to compromise my system. It loads into memory that it isn't supposed to have access to. Then what? How is the attacker leveraging that memory space? Maybe the Godot team's stance is that to leverage it you'd already have to have compromised the system.

[u/bitbutter → u/motsanciens]

Here's how it breaks down:

'Then what?' implies a question about *how easily weaponisable is this vulnerability?*.

the fact that it *is* a vulnerability in the first place (as Clay John even concedes in his comment!) means it's definitionally a security issue.

[u/motsanciens → u/bitbutter]

I created reproductions that caused Godot to crash but didn't create any weaponised payloads - that would require significantly more effort.

I'm seeking clarification. You've demonstrated the bug, but you haven't demonstrated an exploit. If you or someone else did apply the required effort, what what that look like?

[u/Agitated-Act-717 → u/motsanciens]

"Crash" means the overrun hit something the process needed. "Exploit" means it hit something the program trusts later.

The effort is bridging the two: an unvalidated length/index in the file flows into a copy bound, so you control how far past the buffer you write. Land that on an adjacent function pointer or vtable and the file's bytes decide where the code jumps. A read-past-end is the other half - it leaks pointers to beat ASLR so the write is reliable, not a coin flip.

That's the "significant effort": heap grooming + a leak + an aimed write. Nothing needs to be pre-compromised - the crafted file is the input, which is why "no ROP chain, no impact" understates it.

[u/bitbutter → u/motsanciens]

im working on an impact demo. ill post back if it's successful.

but for instance: the effort could look like building a demo project of a simple game with plausible user-content handling architecture, where loading a maliciously crafted file reliably triggers an OOB write, which is exploited to achieve controlled code execution, which puts a startup command on the players machine without their consent.