Many games are heavily modularized, some front-page games even entirely use modules, and for them, the results of something like this would be devastating.
TLDR:
If Roblox were to experience another RCC vulnerablity in the future which could allow re-parenting of serverside instances, or if a game is unknowingly backdoored (some of the biggest games on Roblox have been backdoored before) then it could lead to a source code leak by sending server ModuleScripts down to the client.
Once on the client, the bad actor can simply decompile them like normal.
CAC was affected by this in October, and it should serve as a wake-up call for this to happen to other games.
With this behavior, if the RunContext is Server, reparenting to somewhere client-accessible should error.
“if a catastrophic hack occurs then bad things will happen”.
This is not a bug report. This is common sense. There is no “wake-up” call and there is no bug. Don’t post this stuff here.
If a car crashes, the occupant might get injured. Of course people are doing everything they can to prevent the consequences of the accident, but due to the nature of the situation, it’s prone to problems like this.
Not the best way but, you could prevent this by having the modules crash the server if they’re reparented or have their archivable property changed from false to true (prevents cloning)
This is something I agree with. I’m not sure what’s up with the replies. If my experience somehow gets a backdoor from anything, ALL of my ModuleScripts on the server are prone to being decompiled simply by being reparented.
There’s nothing that can currently be done to prevent this. Additionally, it would be awesome to have my Server & Client Modules all in one shared folder.
Putting hypotheticals aside, it would still be extremely convenient to be able to control ModuleScript bytecode replication.
I like to keep things in one place, which proves to be difficult when certain things require both a client & server implementation (for example, handling all visuals purely on the client, with the server handling the game logic). I would obviously prefer to avoid exposing server-exclusive code to the client at ANY point in time, since it allows people to look for potential vulnerabilities to exploit & also makes it way easier to create a perfect recreation of the server-side.
Example structure
Classes
Class
Abilities
Ability (ModuleScript)
Server (ModuleScript)
Client (ModuleScript)
In the initialization code, I have to manually move all “server” modules to nil in order to prevent decompilation, and that means I have to do it ASAP before anyone gets to have it replicated to them.
I would, however, argue that it shouldn’t throw an error on reparenting, but rather upon attempt to require the module. RunContext controlling where the module can be parented makes very little sense.
this would overall be an unnecessary feature that stems from irrationality that i don’t expect to ever happen
This won’t happen
this could easily mean the entire source is already unsecured
here’s your fix: don’t use modulescripts if you’re this paranoid
trvke
i was going to mention this: it would be insanely easy to attach surface-level anti-tampers to all of your precious modules (in theory, stopping replication).
there aren’t many details on this mysterious RCC vuln.
I just feel like limiting the places where the module can be parented will come with tons of drawbacks. How would the engine figure out whether the reparented instance has any descendants which are modules marked as “server exclusive”? What would happen if the module is placed in ReplicatedStorage, and then marked as server-only?
I don’t really know how the bytecode replication works precisely, but I would assume that since Scripts’ RunContext is able to prevent the bytecode from replicating, the same could be done here too.
There can be a case made for having something like RunContext for modules, namely better typechecking and organization opportunities, but the argument for security here is weak. New features should help the common developer with their everyday needs, not act as a contingency plan for freak serverside exploits like this.
Don’t create your own problems.
If code doesn’t belong to a client, so it shall not be replicated to the client.
There is literally 0 cases where code could be shared anyway. Currently looking at server authority PlayerModule, and it really sucks for the reason it was made to run the same code on the client and server.
All could’ve been avoided by having a LocalScript and Server script specialized for each context…
Feature request is better, but it still wouldn’t work.
If an RCC vulnerability is exploited, there’s nothing stopping that bad actor from turning off any server-only code protection and moving the instances so the client can read them, or just ripping the bytecode themselves right off the server. Same goes for a backdoor, nothing can stop a bad actor from reading the source code and then shipping it off with HttpService or putting it on the client.
This feature literally does that, if bytecode is never exposed, they can’t decompile it. There exists no way to read a scripts Source on the server either.
Your experience shouldn’t be getting a backdoor in the first place, that’s a sign of very poor security on your end that should be resolved before it can even happen instead of letting Roblox give you a crutch that only makes you complacent in your security.
Of course I wouldn’t want my experience to get backdoored in the first place. This is a really weird take. Security mistakes can happen anywhere, especially when it comes to social engineering. You can do tons of work to proactively prevent it, but there’s still always a possibility. Just because it couldn’t happen to me, doesn’t mean it couldn’t happen to the hundreds of other developers who may not follow all of the safe practices. Vulnerabilities are vulnerabilities for a reason, they’re oversights by developers.
…Except that this still returns back to what I originally said. All this does is serve as something that gives those developers a false sense of security, leading them to either become lax or complacent in their security, or worse, never learn how to properly secure and protect themselves online.
The argument of “social engineering” makes no sense here and at that point I’d be more concerned that someone susceptible to that has given the other party access to their entire account, thus defeating the point of this feature as “security” because they have direct access to the original place file.
The only way a backdoor is getting into your game is if you are installing plugins without vetting their source code or using models without vetting their entire contents, which are both very easily stopped by just having the developer be more security aware and careful (and to this end, if the backdoor is in the form of a plugin I would be concerned that the plugin would literally just force module context to client/default and defeat its point).
This is the worst take I have ever seen.. with this same logic we might as well not have any security protections whatsoever, after all your just going to be complacent and lazy.
It might seem easy to just “not get backdoored” but it happens, and when it does games should not have almost their entire server source code leaked in the process. Player data and other such things can be reversed, but you can’t reverse a source code leak.
that would/should require script injection permissions. so no unless you willingly allow it to do that.
By social engineering, I did not mean account access social engineering. As an example, potentially a community contributed asset. I understand that education can be given to developers, but that doesn’t ensure 100% safety.
Just as an example, Roblox is adding Script Sandboxing for toolbox models. Based on your logic, this shouldn’t exist as developers should not become complacent. In my eyes, this doesn’t really follow Roblox’s philosophy.
There’s other ways to have assets reparented if your game is insecure, beyond backdooring. I’m not saying that I would make these mistakes, but it could still happen.
There exists a massive supply chain attack waiting to happen where games that use require(assetId) could all be backdoored if the owners of these modules get compromised. Now I’m not saying that this feature would be a valid substitute for deprecating this behaviour and adding a AllowRequireById toggle to ServerScriptService, but its just one of many methods for how backdoors can happen even if there’s no egregious mistakes on the developers part.
We can and should address how backdoors happen in the first place, but there’s no reason why we shouldn’t also address and mitigiate the damage a backdoor can do as well, and this feature is easily the most important first step in doing that.
The script sandboxing he mentions is actual security that mitigates both the problems you bring up as soon as it is used. This feature is at best just a convenience for developers and shouldn’t be introduced with “security” being any form of a reason or advertisement for the feature.
