SecureLuaVirtualMachine - Controlled Execution Environment

You could, but then exploiters could just delete the restrictions, and mess up the entire game. (I tested SLVM locally a while ago, and yes, it works)

1 Like

Exploiters could just run code without any restriction anyway, as they use their executors which allow them to do so

wait im dumb i forgot lol sorry

not dumber then liker dw dont feel so down

As far as I’m aware, you can add globals in the env but not set the env. (whitelist instead of a blacklist) How can I do this?

Hi - I am having some trouble running SLVM client sided, I forgot how I did it lol.

Ok never mind.

@HexadecimalLiker, Could you please explain this in a little more detail with an example or something along the lines of that? I’m having trouble with it.

Security Advisory

SecureLuaVirtualMachine had two important security vulnerabilities.

SecureLuaVirtualMachine had a security vulnerability that could be used to disable every AdditionalSetting , including SandboxCalls .

Alongside this change, we have also fixed an vulnerability with TFORLOOP allowing you to bypass virtualization.

Technical Details Vuln #1 (AdditionalSettings overwrite)

The first vulnerability was possible because the SLVMEnums table was accessible through the shared global, allowing malicious actors to write to the AdditionalSettings table inside SLVMEnums.

An attacker could have executed something along the lines of:

shared.SLVMEnums.AdditionalSettings.SandboxCalls = 0 --> Disable SandboxCalls
shared.SLVMEnums.AdditionalSettings.ThrottleRecursiveCalls = 0 --> Disable ThrottleRecursiveCalls
shared.SLVMEnums.AdditionalSettings.ThrottleLoopInstructions = 0 --> Disable ThrottleLoopInstructions

This was patched by making the SLVMEnums table (and all other tables within it) read-only via table.freeze.

Technical Details Vuln #2 (SandboxCalls Bypass)

The second vulnerability was possible because TFORLOOP didn’t sandbox what iterator was being called, resulting in potential malicious actors to be able to do something like this:

local func do
    for f in debug.info, 2, "f" do --// Calls debug info without sandboxing (callstack exposed)
        func = f
        break --// Break to avoid error
    end
end

warn(debug.info(func, "slnaf")) --// Would return the actual function instead of generic ``pcall`` (indicating call was sandboxed)

This was patched by making TFORLOOP’s iterator function called through isolate_call_synchronous.

Please update ASAP: Secure Lua Virtual Machine.

Additionally I’d like to point out that you cannot bypass AFAIK the Blocked Globals and Hooks. So forbidden services would STILL be blocked. You normally aren’t vulnerable to being bypassable regarding the Blocked Globals and Hooks if you have set up SLVM correctly.

On another note, SLVM V2 will be coming soon. It will be safer, faster and easier to integrate.
Big thanks to @CodedJer and @Unlimited_Objects for testing.

I now finally get to sleep. :sob:

6 Likes

I cannot emphasize how important it is to update, please update immediately, as soon as you can!

5 Likes

Anyway to put this resource on an external site like GitHub? Roblox has this resource private on the catalog and am unable to access it. Thanks!

3 Likes

Seems like the asset was unfairly removed removed from the catalog :frowning_with_open_mouth:

@HexadecimalLiker has just appealed this, thanks for letting us know

2 Likes


The Roblox moderation team still doesn’t want to put back the model onsale. I will upload the SLVM rbxm file to github and link it there.

They took one single minute to review my report, which makes me feel like it was completely ignored.

EDIT: Here is the github link GitHub - AstonishedLiker/SLVM

8 Likes

Any Update?
Great resource but I’d personally like to know if it can be used in production without going against TOS

2 Likes

Sorry for the very late reply. No, SLVM doesn’t break ToS, it just appears that SLVM simply goes against Roblox’s Creator Store policies, besides being totally safe.


Keyword: “LuaVMs”


anyway i can use requires but still keep sandbox?

No, you can’t, as it is out of the VM scope.

Hi! I’ve been really confused about completely banning instances from being accessed, returned, and possibly just not being accessed outright because the current Rule system seems specific for only certain commands! How could I aim to completely ban instances? My use-case would be to make a custom wrapper API that handles the work so the users would call our predefined global tables and functions.