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.
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.
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.
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.
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.
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.
Modules and models are both attack vectors, but this module is being used as an attack vector. The same person or friends of the same person controls the model that is being widely disseminated, something that is also an attack vector. I believe there is a decent chance, based on previous situations with the module, that the model will be used maliciously in the future.
@einsteinK yes, but there are supposedly hacks which allow execution of code as if it was server-side. Maybe these days are gone completely, but I will not bet on it. I did also mention insecure remotes, which are not malicious but are an attack vector.
I’m pretty sure there currently isn’t an exploit to run serverside code in an empty place, FE or not FE. There might be insecurities with RemoteEvents, but you must’ve been doing very weird stuff to have a Remote that allows running code on the server (or requiring/loadasseting any model)
I am not running any code to insert arbitrary models because I know they are an attack vector. I also do not own the chair model. The same cannot be said for everyone on ROBLOX.
On the contrary. It’s been an ongoing trend over years to decrease the power of inserting models. Long ago, a client could insert any model on the server. Now, it’s pretty restricted:
I’ve seen @ConvexHero mention roblox might think about better support and security for third party code. (from his descriptions, seems like an official NPM-ish thing for roblox is what he has in mind, which would be very nice) Could take a long time before those functions and/or security things are implemented, but it doesn’t seem like the trend of “more security, less ways to load (unauthorized) external code” is about to stop, let alone revert.
ROBLOX is getting pretty good at not having security holes, but some have appeared in the past and some may appear in the future, which is my concern.
Maybe InsertService will go away forever at some point? I will be sad, because I know several communities that use inserting models as social features, but I won’t worry about models being an attack vector outside of social engineering.
Hacking, mostly. There may be no hacks able to insert models currently, but there may in the future despite the good work ROBLOX is doing. Things unimaginable like the bad server from September 7th to 9th.
I don’t want anyone to have any pleasure from modifying ROBLOX games en masse to distribute a model which in the future is used to have fun in or destroy specific vulnerable games, whether the vulnerability is on the game creator’s side or ROBLOX’s.
Or have any pleasure from modifying ROBLOX games en masse for unexplained reasons period, which is currently happening.
With FilteringEnabled (also being checked on the server), I doubt there’ll be an exploit to insert stuff on the server.
The bad server thing from a bit ago had nothing to do with InsertService, or even anything in-game. They found a way to start an unprotected Team Create server for (some) places, which they then connected to edit the game. That’s a lot different from executing any kind of exploit in-game.
Given how prolific model/place copying is, require() is one of the precious few ways to protect our source code from plagiarizers. Not to mention it makes remote-updating blissfully simple. Find a solution that doesn’t ruin the lives of countless scripters, please. Thieves shouldn’t prosper off of our hard work. I know information wants to be free, but some scripts absolutely need privacy to remain viable.