hexcede / h6x Goto Github PK

Describe the bug
This error has popped up unexpectedly and was reported by one of my users.

To Reproduce
Steps to reproduce the behavior:

1. Run security test
   

Version information (please complete the following information):

• H6x version: 2.1.1
• Beta features enabled: Parallel Lua

This is an example of how you might word or structure a code compatability issue. You don't have to do it exactly this way but it's helpful. This was a real bug encountered in-dev before the release of v1.1.220607.

Describe the bug
This code causes H6x to hang Roblox.

To Reproduce
When the code runs, sandbox:GenerateActivityReport causes a hang.

This code demonstrates the issue as best as possible and is as small as possible:

local sandbox = H6x.Sandbox.new()
sandbox:ExecuteFunction(function()
	abc = function(a, b)
		return b, a
	end
	b, a = abc({ABC = abc}, 2)
	a.ABC(4, 5)
	a:ABC(8)
end)
sandbox:GenerateActivityReport("h6x") -- Caused by this (commenting this line makes the code work)

Expected behavior
The code runs correctly without hanging.

This code demonstrates the expected behaviour when ran outside of the sandbox (leave unchanged if N/A):

CODE HERE

Version information (please complete the following information):

• H6x version: v1.1.220607
• Beta features enabled: All beta features

Additional context
After investigating the issue and debugging it myself, the hang is caused by a table.find call inside of sandbox:GenerateActivityReport(). table.find does regular == comparison, which causes a new log entry to be created before sandbox:GenerateActivityReport() is finished, resulting in the pairs loop on log history to never complete.

Describe the bug
Calling a user data object with the metamethod __call fails to check whether it's a C function, results in an error using debug.info with argument 1.

To Reproduce
Steps to reproduce the behavior:

1. Create a module script that returns a user data object
2. Require the module and attempt to call the returned user data
3. Expect to see a bug similar to this
   

Expected behavior
Calling it must not encounter an issue with user data

Version information:

• H6x version: v2.1.0
• Beta features enabled: Parallel Lua

Describe the bug
As demonstrated in #8 globals from tests end up in the base environment the sandbox uses. This is not necessarily a security concern but is potentially confusing behaviour as it is the default and providing custom base environments is not super clear.

To Reproduce
Steps to reproduce the behavior:

1. In a sandbox, print the caller fenv:

print(getfenv(2))

2. Notice the globals from tests (as seen in #8).
   

Expected behavior
By default, writing to the global environment from a sandbox would not be expected to modify the base environment. This can be solved by using another layer for the Environment object for storing raw changes, rather than transferring them to the base environment.

Version information (please complete the following information):

• H6x version: v0.0.x-v1.x.x
• Beta features enabled: All beta features

Additional context
See #8

There's a vulnerability inside user code where it can mess with the global H6X.

Reproducing the bug

1. Server Runner executes user code

warn(getfenv(2))

2. Bug occurs with the global table

Expected behavior
Prints out the global H6x table

FX Script 327713710-734a0c06164e71:  ▼  {
                    ["globalH6x"] =  ▼  {
                       ["Constants"] =  ▶ {...},
                       ["Environment"] =  ▶ {...},
                       ["Logger"] =  ▶ {...},
                       ["Reflector"] =  ▶ {...},
                       ["Runner"] =  ▶ {...},
                       ["Sandbox"] =  ▼  {
                          ["Empty"] =  ▶ {...},
                          ["Plugin"] =  ▶ {...},
                          ["Roblox"] =  ▶ {...},
                          ["User"] =  ▶ {...},
                          ["Vanilla"] =  ▶ {...},
                          ["new"] = "function"
                       },
                       ["SandboxActivity"] =  ▶ {...},
                       ["Testing"] =  ▶ {...},
                       ["Util"] =  ▶ {...}
                    },
                    ["globalSandbox"] =  ▶ {...},
                    ["globalThing"] = "someNotVerySpecificString",
                    ["script"] = Sandbox,
                    ["testMulti"] = "function",
                    ["thread"] = "Thread(24B3FD890F8)"
                 }

Screenshots

Version information (please complete the following information):

• H6x version: v0.0.220515
• Beta features enabled: Parallel Lua

Additional context
I wasn't sure if this bug was necessary or not in terms of allowing user code to access the global H6X table. I wanted to point this out because it could access H6X module and possibly tamper its functions.