I wouldn’t mind a type of “PrivateModule” type system, with the setting being based on the name of the module. MainModule would be public (thus backwards compatible), PrivateModule would be private (the desired private behavior), and anything else wouldn’t do anything.
6 Likes
If I remember correctly, loading modules you don’t own only works if the module is called MainModule (not the model name, the ModuleScript’s name). You should be safe as long as you give it a different name.
I’m hoping the MainModule system won’t get removed.
They have to be named MainModule to be required by ID though. Otherwise they have to be inserted and OP’s code has to be changed (but again, less of an impact than the large base of existing code that’d have to be changed if this was removed)
2 Likes
Yes there are several issues here. On one hand, you might want to share a module but not the code. On another hand, you might want to prevent your place from loading any code not owned by your place. There is also a possible desire to get a specific version of an asset vs the most up to date version.
It might also be desirable to have restrictions on what API could be used within a modulescript that you do not control. For example, SavePlace, InsertService, DataStores, HttpService, etc… could be restricted. Even access to workspace/Players could be something that could be restricted in math-only modules. It may also be desirable to consider a modulescript similar to a networked client where the modulescript can construct objects in a special container and then trigger an event.
Restricting access to httpservice, require/insertservice, and a few other APIs prevent a script from phoning-home to determine if they should break, assuming a specific version is forced.
These topics may come up next year during the planned efforts to improve filtering enabled.
6 Likes
I’m happy with the current system. I thought it was common knowledge that this was (now) considered intended behaviour.
2 Likes
Crazy idea, but what about runscript(assetId/LuaSourceContainer,environment)? It would look like this if written in Lua:
local function runscript(from,env,...)
local func
if type(from) == "number" then
from = getMainModuleFromAssetId(from) -- error if not found
func = loadstring(from.Source) -- error if parsing error
elseif typeof(from) == "Instance" and from:IsA("LuaSourceContainer") then
func = loadstring(from.Source) -- error if parsing error
else
error("Expected number / Instance")
end
env = env or createDefaultEnvironmentForScript(from)
setfenv(func,env)
return runWithClearCallstack(func,...)
-- getfenv(0) (the thread environment) in func() should also be env
end
The vararg isn’t that necessary, since using ... in the “root” of (module)scripts does nothing now and would be weird if it suddenly did. and we can just make the script/module return a function, or pass variables in the environment
If we don’t add vararg, we can “leave the arguments space” available to add other stuff, e.g. security stuff (like you suggested) when/if it’s implemented. (although since we can specify the environment, we can sandbox it just the way we want it) One example would be a timeout, so we can protect against infinite loops and string.rep("crash",1e99)
this function seems much easier to implement than all the security stuff and API restrictions you mentioned, while it also allows us to do much more, since we can sandbox it just the way we want it
Example of something what this would allow
Just a stupid example that could be fun to implement, but not that useful or so
Have an uncopylocked module for your game that looks like this:
return {
Theme = "Dark";
Keybinds = {
G = "Grenade";
E = "Inventory";
};
}
Have a “Load Settings” GUI where people enter an assetid and this happens:
local settings = runscript(enteredAssetId,{})
settings = merge(settings,DefaultSettings)
Basically allows people to easily load settings. Doesn’t seem that useful for one game, but for scripts that are in a lot of different games (like admins) or if games use the same settings.Keybinds format, it would allow for nice stuff.
and because we just gave an empty environment, they can’t do any damage, except infinite loops or string.rep with a high number. maybe one of those “security options” should be a script timeout
Another example would be adding Instance/Color3/UDim2 to the environment and allow people to create their own UIs (well, take the one from the uncopylocked model and edit it a lot)
just another crazy idea
These crazy ideas for players aside, this feature would actually be quite useful for developers. Apart from being able to relatively safely (sandbox) load external modules, we could also sandbox our own scripts/modules for testing purposes. E.g. disable scripts/modules and manually run with sandboxed environments that keep track of require() calls, DS requests, …
5 Likes
As much as I don’t want this behavior to go away, it’s clearly being abused:
https://www.reddit.com/r/roblox/comments/75owub/psa_remove_kohls_admin_infinite_from_your_game/
Who knows what the chair is for? He can update it with whatever payload he wants and insert it into games since a lot of players own it.
Uhm, talked to Kohl about this one.
First of all, it’s just a normal chair model, unanchored and unwelt at that.
Secondly, it was made for a meme so I don’t really understand how this is a danger?
Lastly, it hasn’t been updated in 2 years and he doesn’t plan on updating it either.
Plus this certainly doesn’t relate to modules being removed, the chair is a model.
Wait, so they actually admitted they abused the trust of their users?
3 Likes
Khol says he isn’t going to do anything malicious. So what?
The chair has everything to do with modules because the marketplace prompt payload was injected into every game his admin script is in via the closed-source module he can edit at his whim. He is literally modifying half of ROBLOX’s games without the creators’ approval. He has also taken steps to avoid creator’s ire by deliberately not displaying the prompt to them. If that doesn’t sound fishy, I have bridges in stock now.
His word that he won’t do anything means absolutely nothing.
2 Likes
Whoa, let’s not start a hate thread here. I already feel like I shouldn’t have asked the question in the first place. But let’s instead see if what occurred makes a legit reason to actually remove the ability to run non-owned modules.
Discuss ideas, not people.
6 Likes
I don’t think it warrants for the removal of non-owned modules. Back with the original Kohl’s Admin, saying “!hitler username” or something like that would give that person admin in the game. This was plainly visible in the source for years and no one caught it because they didn’t bother looking.
If we remove the ability to run non-owned modules, this will still happen because we can’t force people to review the source of what they’re using, especially on a seemingly-trustworthy (so many people using it) model. My thoughts are: give closed-source modules a permission system as suggested previously, and if no one bothers to check it then it doesn’t matter because they’d fall victim to an open-source model as well.
Edit: It might also be a good idea to log modules’ usage of permissions so I could differentiate something like prompting to take a model of the admin commands every now and then when a user clicks the Credits button or something versus prompting users every time they join the place to take a random model.
4 Likes
The parties involved in the Molotov-Ribbentrop Pact are incidental to the point I was trying to make; kohl can change his mind at any time about not updating the chair to deliver a payload.
The fact is that the private module is already being used as an attack vector to inject the PromptPurchase payload into every game that has the script. It has supposedly happened before with different payloads doing things like bouncing specific players between games to generate millions of tickets. Will the innocent-looking and not-malicious chair model be updated to contain a payload? It can, and there is a history of this kind of tomfoolery, which concerns me.
I am curious of what ROBLOX Corp.'s stance is on this debacle.
I will note that Workspace.AllowThirdPartySales does exist as a limited form of protection against rogue scripts selling arbitrary items in a place. In this case, free items were allowed due to dev feedback. I don’t think this was mentioned on the wiki.
There are several issues with using 3rd party, auto-updating code. This is in terms of intentional malicious updates (both original user and compromised user), insecure updates, and non-backwards-compatible updates. IMO this is not related to using private modules. It is based on the lack of a sandbox for 3rd party code and the lack of a selected version option for 3rd party code. These are both desirable, complex, confusing, and error-prone features.
3 Likes
I fail to see this as a point at all, it collapses on itself.
You’re using the chair model as an example but that doesn’t relate to the actual question. And the question “will it be malicious” can’t be asked either, because the chair is just that, a model. You’re arguing to both remove site module requiring and removing freemodels with that point.
Note that for the chair to have any effect, the user must insert it themselves via Studio into the game. And I can confirm that the chair isn’t even automatically inserted into the game.
The “what if” argument holds no ground in this case because you’ve begun to blur the line between model and module, malicious or not.
Third party private modules are starting to seem less useful and more sketchy.
I made an argument for them last year based on IP enforcement. That argument doesn’t work because there’s no official channel for making money through models, so IP enforcement isn’t useful for them.
There isn’t a legit reason to hide stuff in code that you’re giving away for people to use imo.
Distribution control.
1 Like
No. The module is an attack vector currently modifying games against the wishes of creators and purposefully hiding itself from them. The model is also an attack vector but is currently not attacking anything; you are falsely conflating the two in my argument. The chair is more than bricks, it is an inventory slot that can be updated at any time and inserted into games.
Models have been malicious in the past and there is no reason this will change. Remember when people were randomly getting teleported from games into these baseplates and generating millions of tix?
In that case, the model was a teleporter created by roblox. It had all the properties of a malicious model:
- able to be inserted in the game
- able to be modified to create malicious behavior
and malicious users did both.
The chair model has the same qualities:
- the chair is able to be inserted in many games (due to many people owning it)
- the chair can be modified to create malicious behavior (by updating the model)
So does the admin script:
- the admin script is inserted in many games
- the admin script can be modified to create malicious behavior (and is currently modified to create malicious behavior [and has been modified to create malicious behavior in the past])
The only thing the model attack vector is missing is one insecure remote or one InsertService exploit and it can be inserted.
Technically, all models owned by other people are attack vectors, but this on the small scale I have not seen nor heard of. The widespread dissemination of the chair model is cornering because it greatly expands the umbrella of potentially-affected games, and given the current situation with the admin script, and the past situations with the admin script, I find I would rather not take the chance that nothing will ever happen with the chair model.
For what it’s worth, I apologize for my earlier unsavory comparison.
1 Like
Didn’t they make it only the server can use LoadAsset? If so, it doesn’t matter which models are in the creator’s inventory, as they can only be inserted from the server, which would only happen if there’s already malicious code present anyway.
1 Like
Not sure why the module is the problem. I could dynamically insert assets through InsertService in a regular script. You could argue that with a script you can tell unlike a closed-source module, but the people affected aren’t the type to check (or even understand) script source.
The problem is that third-party scripts have full access to the game, public source or not.
1 Like