ZDoom

This has been coming up in Discord a lot and probably should be addressed here, too.

Versions prior to 4.14.0 had a backward compatibility for older ZScript versions that became problematic later on. In particular, type checking was not fully enforced when accessing one type as another.

This technically was patched but the patch was version-gated. Unfortunately more people were starting to discover ways that this could be exploited, and it eventually led to a vulnerability proof of concept being developed.

This created a conflict between two guiding goals of the source port: Maintaining backward compatibility, and keeping GZDoom in a state that would make most people feel like it is generally safe to use (i.e. vulnerabilities like this patched out).

In general, most people do not want to get their computers infected with malware just by downloading and installing a mod for a game, and there is often the expectation that mods cannot do that (or, you at least generally assume that it's too difficult to exploit for it to be worthwhile). GZDoom's community is vast, and while we have not directly seen malware being distributed in the form of GZDoom mods, there have been increasing concerns over this being a potential attack vector, and it likely would set a bad precedent to wait until one appeared, so it was decided that it had to be patched out.

So - some mods broke with the 4.14.0 update, unfortunately, and that was something we could not avoid. The goal of keeping GZDoom safe won out over maintaining backwards compatibility. While this doesn't prevent potential issues if a mod includes its own executable files, running them is ultimately your choice. If you double-click that .exe, you already understand that the GZDoom developers have no control over what happens next.

It goes without saying - update your GZDoom!

Thanks for the clarification. I think as long as portable versions for Linux is available this becomes easy to navigate as you can use DoomRunner to have many different versions of gzdoom active and only use the older versions on older mods and wads while using newer stuff on the latest GZDOOM to avoid new ones exploiting the vulnerability.

EDIT: I see that .deb files can just be extracted and used as portable versions as far as I can see so that is helpful.

As someone who has a few mods that use code which broke due to this, I totally support the decision to make the change.

Is it frustrating? Of course it is: some of my stuff broke and it is in areas that are too complex for me to fix on my own. It's code that I took from resource mods and I don't fully understand the details of how it was doing what it was doing. So, there will be a time delay, and I will have to enlist the help of others to get it fixed.

That doesn't mean it was the wrong decision though. Closing down the possibility of a potentially harmful exploit is absolutely the right thing to do. In this case, very unusually, it meant that breaking some backward compatibility was necessary. That isn't usually the case. The GZDoom developers often go to great pains to find non-breaking ways to fix things. The decision would not have been taken lightly.

The sad part, as we all know, is that - sooner or later - there would be someone who tried to use the exploit to cause harm to peoples' computers. That's where the real problem lies: people acting maliciously, and not with the GZDoom devs who are trying to prevent such actions from being possible.

Thank you, Enjay - yes it wasn't a decision that was made lightly, and I hope it's the last time we have to break anything to fix such serious bugs.

Worth drawing attention to:
Perhaps one of the more popular mods that has been affected, m8f's Weapon and Inventory Gearbox, has been updated to work with the new GZDoom.
viewtopic.php?p=1257212%3A#p1257212

And that's how it should be - this attitude of "screw it - I just continue to use the old version" is one of the biggest problems with vulnerable software in general. It is very hard to get the vulnerabilities out of the system if people just to refuse to update for often questionable reasons.

Hey, I'm glad that you're taking your responsibility and that you're committed to a secure and reliable application.

I was wondering though, how big was the impact? Could user data be accessed for example?

The Flatpak version of GZDoom is sandboxed, not giving /home/ access by default. While this attack was only hypothetical, I'm curious if the containerisation could have prevented it.

The impact is the same as for any other sandboxed application where you get to run arbitrary code: you can do anything the sandbox allows you to do. If you want to know what the sandbox in flatpak allows you need to ask the flatpak team.

@dpJudas, I'm the flatpak team . I'm just asking if the bug in question allows arbitrary code execution on the host machine.

For the record, if that would happen with the Flatpak version of GZDoom, the damage would be limited. /home/ can't be accessed and the container doesn't contain any remote control tools

I think I already have my answer, here are the technical details:

https://github.com/Chainmanner/GZDoom-A ... Script-PoC

I meant the designers of the flatpak sandbox system, unless that is still you.

Geez, that is quite a serious vulnerability! https://github.com/Chainmanner/GZDoom-A ... Script-PoC
Can someone confirm if this is actually the vulnerability in question or is there another serious one since the link mentions it being fixed in 4.13.2


Whatever vulnerability it is backwards compatibility is always gonna lose against something like arbitrary code execution. Think I'll just stick to the latest GZDOOM.

If it is indeed present in ZDOOM and LZDOOM it might be irresponsible to link to them under the downloads section without at least some kind of warning or one off patch - same goes for the archives (probably too hard to patch but at least a warning so casual folks don't wreck themselves.)

Here are the PoC's I published to Discord

This is the one that got patched by breaking ZScript. This proof-of-concept was also made by Chainmanner.
This one was another case of a misinterpreted pointer that could be used to create arbitrary code executions. This one was made by RaveYard.

I wonder if anyone is going to do an exploit hunt to see if anyone has been exploiting this in the wild in all the broken popular mods: Would be interesting to see if anyone hasn't been playing nice.

The Doom community generally maintains high standards, with only a few notable exceptions. Most of these arise from projects distributing .exe files, which quickly fail once the malicious code or actions are discovered, damaging the author's reputation and future contributions.

This mainly applies to active members of the Doomworld, ZDoom, and Zandronum communities. Those outside these circles are less bound by rules, but so far, I haven't seen attempts to exploit vulnerabilities. I also ensure that the latest version is available across all of our target platforms before sharing details about any exploits.

GZDoom is likely too small to be a prime target for zero-day exploits. While it has never been immune to such threats, the effort required typically outweighs the benefits. Exploiting major operating systems like Windows, Linux, or Mac offers access to millions of users, making them far more attractive targets for those motivated by such activities.