@Sponge said in the Random Bitching thread:
Help me out here. I always u(), I never eval(), I work in TinyMUX. What's the deal?
This is meant as a primer in security on u(), not as a direct answer to Sponge's question, however I touch on a few points that he, and other MUX runners, should note.
In TinyMUSH, u() did it's evaluation based on the TARGET. This tends to form the basis of the functionality of the derivative codebases. This means that u() evaluates from the perspective of the object performing the function. Since most codebases today are lineage-traced to TinyMUSH, this behavior has carried over. It is like this in MUX.
Consider this example. I am an Immortal/Wizard:
&TEST me=[set(*Guest1, Royalty)]
@set me/test=VISUAL
Now, anyone can do this:
(As a guest): think [u(*Rook/TEST)]
Lo and behold, Guest1 is now a Wizard. Ta Da! WTFJH, you ask? Well, since u() evaluates as the target, it was using my permissions (as a Rhost Immortal/Wizard) to execute that function. Once you think about how many games upload code given to them, or they find on the internet, the dangers of this behavior can quickly scare the shit out of any non-coding game owner. Imagine if Anomaly's +JOB code had a hidden command in the file that did exactly this? This has actually happened on games in the past, this exact sort of hidden backdoor exploit that was put in place by malicious staffers with WizBits in the event that they got fired.
In Penn and Rhost, but only in these two codebases, you have the option to disable this type of behavior using the safer_ufun config parameter, which forces the game to evaluate attributes on things you do not control at your bit level or the object's level, whichever is LOWER**. Since objects do not have bits, this only makes sense on INHERIT objects... which means the stuff in your Master Room that are usually owned by a Wizard.
@admin safer_ufun=1
Set.
think [u(*Rook/TEST)]
Permission denied.
Now Penn and Rhost will give you the bold-faced middle finger. MUX... well, you really need to check all of your code for side-effect functions being used.
**And in Rhost, additional security is in place to force the target to have SIDEFX flag set on the target before side effect processing (such as set() ) is allowed. The benefit of this two-fold security is that you can set only specific objects to be allowed to process SIDEFX functions such as set(), things that really should have it because of coded systems.
