Bagnon causes restricted enviroment lock?

[MunkDev]

I'm currently using some table manipulation inside the secure environment, where I gather unit frames by recursively scanning the UIParent and inserting all protected frames with a unit attribute assigned into a restricted table.

This works flawlessly - until I open interface settings. After that, attempting to run the snippet that gathers nodes results in this error:

1x FrameXML\RestrictedExecution.lua:397: Call failed: FrameXML\RestrictedExecution.lua:397: Call failed: FrameXML\RestrictedExecution.lua:397: Call failed: FrameXML\RestrictedInfrastructure.lua:365: Cannot create restricted tables from insecure code
[C]: ?
FrameXML\RestrictedExecution.lua:397: in function <FrameXML\RestrictedExecution.lua:390>
(tail call): ?
(tail call): ?
FrameXML\SecureHandlers.lua:283: in function <FrameXML\SecureHandlers.lua:277>
(tail call): ?
 
Locals:
workingEnv = <userdata>
ctrlHandle = <userdata>
pcallFlag = false
LOCAL_Function_Environment_Manager = <function> defined @FrameXML\RestrictedExecution.lua:209
error = <function> defined =[C]:-1
tostring = <function> defined =[C]:-1

Naturally, I turned to the trustworthy taint log to see what the hell happend. After sifting through all the bloat I found this:

11/25 00:02:09.812  Execution tainted by Bagnon while reading BagnonFrameinventory - Interface\FrameXML\UIParent.lua:2784
11/25 00:02:09.812      securecall()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:2824 CloseWindows()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:2852
11/25 00:02:09.812      securecall()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:3532 ToggleGameMenu()
11/25 00:02:09.812      TOGGLEGAMEMENU:1
11/25 00:02:09.812  Execution tainted by Bagnon while reading BagnonFrameinventory - Interface\FrameXML\UIParent.lua:2784
11/25 00:02:09.812      securecall()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:2824
11/25 00:02:09.812      securecall()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:1966 <unnamed>:ShowUIPanel()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:1880
11/25 00:02:09.812      <unnamed>:SetAttribute()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:2630 ShowUIPanel()
11/25 00:02:09.812      Interface\FrameXML\UIParent.lua:3543 ToggleGameMenu()
11/25 00:02:09.812      TOGGLEGAMEMENU:1

By disabling Bagnon, the errors disappear and I can continue to securely manipulate tables after opening the interface settings. So far, I've had no taint issues with Bagnon, but attempting to manipulate tables after viewing the interface settings seems to cause a complete meltdown.

So what I'm really asking here is:

1. Can I prevent this from happening or is the problem only related to Bagnon?
2. Can I determine whether I'm running a tainted execution path and thereby circumvent the lockdown?

Here's the actual code, but it's all executed within a secure enviroment and using secure buttons to trigger changes within.
It works regardless of combat state and hasn't broken down in any other scenario thus far.

[jaliborc]

The only thing I can think of is that Bagnon uses the ColorPickerFrame in the configuration panel.

[Resike]

What are you trying to accomplish? Trying to hook the functionalty of every unit frame from the UIParent?

[MunkDev]

Originally Posted by Resike What are you trying to accomplish? Trying to hook the functionalty of every unit frame from the UIParent?

Four secure buttons are each given a direction, which is used to find the most appropriate selection from a table of unit frames. The wrapped pre-body generates a unit attribute, which is then attached to the button and fired immediately afterwards. The result is a one button press to both find the next unit frame and "click" that unit frame. The most appropriate unit frame is determined by looking at where the unit frames are drawn on screen. The cursor you see in that gif is just smoke and mirrors.
I'm not actually hooking anything.

[MunkDev]

Originally Posted by jaliborc The only thing I can think of is that Bagnon uses the ColorPickerFrame in the configuration panel.

Is that normally a culprit in issues like these?
I can't say for sure that Bagnon is causing the issue, but disabling it solves the problem.

This is the part where shit hits the fan:

local children = newtable(self:GetFrameRef("UIParent"):GetChildren())

[MunkDev]

I figured out a workaround, which involves scanning the children of UIParent outside the secure environment and then pushing the frames onto a stack one by one if they are protected.

Attempting to insert something tainted into a table created in the secure environment is most likely what caused the problem. Since InterfaceOptionsFrame is a child of UIParent, it would be included in the table if the scan is done outside of combat. Why specifically Bagnon seemed to be the culprit, I'm not sure. But this solution works:

function ConsolePort:UpdateSecureFrameStack()
    if not InCombatLockdown() then
        for i, child in pairs({UIParent:GetChildren()}) do
            if not child:IsForbidden() and child:IsProtected() then
                UIHandle:SetFrameRef("NewChild", child)
                UIHandle:Execute([[
                    FrameStack[self:GetFrameRef("NewChild")] = true
                ]])
            end
        end
    end
end

-- Changed this to only scan a predefined table instead of creating a new one
UIHandle:Execute([[
    UpdateFrameStack = [=[
        Nodes = wipe(Nodes)
        for Frame in pairs(FrameStack) do
            CurrentNode = Frame
            self:Run(GetNodes)
        end
    ]=]
]])

[semlar]

The taint log is pointing to bagnon inserting its frame into the UISpecialFrames table which is read by the CloseSpecialWindows function in UIParent.lua.

Your error itself is being caused by "newtable" being called from a tainted execution path, and frankly I don't know how that's even possible.

[MunkDev]

Originally Posted by semlar Your error itself is being caused by "newtable" being called from a tainted execution path, and frankly I don't know how that's even possible.

It's possible because handle:GetChildren() will still return unprotected frames in the secure environment when you're not in combat. Since they are unprotected, they can very well be tainted. It's kind of a trojan horse in the secure environment.

[semlar]

Originally Posted by MunkDev It's possible because handle:GetChildren() will still return unprotected frames in the secure environment when you're not in combat. Since they are unprotected, they can very well be tainted. It's kind of a trojan horse in the secure environment.

Any frame created by an addon that isn't secure is, by definition, tainted, so unless bagnon is the only thing you're running with a child of UIParent something else would also trigger it.

Here's an example that outputs all unprotected children of UIParent when you mouse over a unit. If you're in combat, GetChildren() will simply not include those frames, it doesn't freak out about a tainted execution path.

local f = CreateFrame('frame', nil, UIParent, 'SecureHandlerStateTemplate')
f:SetAttribute('_onstate-mousestate', [[
    if newstate == 'on' then
        for i, f in pairs(newtable(self:GetParent():GetChildren())) do
            if not f:IsProtected() and f:GetName() then
                print(f:GetName())
            end
        end
    end
]])
RegisterStateDriver(f, 'mousestate', '[@mouseover,exists] on; off')