As a Roblox developer, it is currently hard to stop exploiters/backdoors using setfenv/getfenv.
Similar to loadstring, these functions are highly used by exploiters to do much more than usual. Luckily there’s a LoadStringEnabled property to disable it, however not for setfenv/getfenv.
I propose a property which acts just like LoadStringEnabled but for setfenv/getfenv (perhaps named FenvFunctionsEnabled?). By default, this property would be enabled for backwards compatibility yet developers would be highly advised to disable it.
Additionally, this’ll help newer developers protect against backdoors which use getfenv.
I agree with this idea. From what I understand, I can only see it as beneficial.
A majority of my exploit prevention systems are triumphed by the fact exploiters can utilize these functions and gain access to functions they wouldn’t otherwise have easy access to. If this feature was implemented, it would be a major step in the right direction when it comes to anti-exploitation systems.
Unfortunately, I’m no Lua engineer so I wonder if this would be possible without major modifications.
Even though it would be a nice addition, I think this would cause some collisions, some not malicious modules might be using setfenv/getfenv (even though it’s technically bad design and you shouldn’t do it) which would stop them from working. Unlike loadstring which there is 0 reason to use it unless you’re doing something sneaky, setfenv/getfenv are used quite often. And as well from my experience I don’t know many spooky things that setfenv/getfenv does, besides setting the environment to be an empty table thus globals are no longer accessible which might cause your entire game to error setfenv(0, {}), but this only happens if you called a function offered by the module. Oh, and disabling some of luau’s optimizations
They don’t need to use the Roblox engine to execute exploit scripts that use getfenv and setfenv as far as I know. However, this still would be a great step in stopping a majority of exploiters that can’t afford fancy exploit programs.
Be aware that there are quite a few use cases for getfenv/setfenv in production games and plugins, as covered by a previous survey thread back when it was being evaluated for Luau. Making a property like this for new games would make quite a few free models just not work, and some don’t have workarounds. https://devforum.roblox.com/t/do-you-use-setfenv-and-if-so-why/236325
My game has a single ModuleScript with the code return(getfenv()) that is referenced by my game’s data system so it can optimize and reuse the results from pure expressions. For example when I type "Example: " .. game.PlaceId, my compiler knows that both the .PlaceId and concat operations are pure, so it can be expressed as “data” using something like this: concat("Example: ", index(index([env], "game"), "PlaceId"))
That’s my getfenv use-case, but if needed I suppose it could instead return {game = game, math = math, ...}.
I really don’t think disabling getfenv/setfenv would stop exploiters though.