Possible PIN number loophole

[Yichard]

In short, the LSL function llSetRemoteScriptAccessPin allows to associate a PIN number to a prim. Later, knowing this PIN number allows a master script to load a slave script in that prim, which can then modify it. This is commonly used for automatic updates of products, and I propose the use of this for things like gardener robots, which become able to update or grow plants.

This PIN number then gives the power to a script to modify or delete other objects, owned by other persons. This is very useful, but also dangerous, and for this reason, there is no llGetPinNumber function, and we cannot know the PIN number of an object.

The loophole is when a person x gives an object with a PIN number to a person y. The person x then keeps the power to modify or delete the objects belonging to y, by accident or deliberately.

llCheckPinNumber would not work, as it supposes there is a script to use it, which is not the case if the bad action is intentional.

So the idea is that the receiver of an object gets a warning when this object has a PIN number, and gets the power to remove it. Example: "The object xxx you received has a PIN number set. This allows other scripts to modify it. This has legit uses, for instances for merchants to update their products. But in other cases the previous owner keeps the power to modify or delete your object. Keep the PIN number? Yes - No.

[Yichard]

Uh oh it was 2 AM when I wrote that... I had not read the documentation: If target is not owned by the same person, and name does not have transfer permissions, an error is shouted on DEBUG_CHANNEL. Other protections are here http://wiki.secondlife.com/wiki/LlRemoteLoadScriptPin

So I need to close this myself, lol

[appurist]

Yeah we've been down this road before, and as far as I know, fully reviewed this function and plugged the holes.

There used to be a huge vulnerability in the OpenSim version that we fixed in Halcyon too, where there was a default PIN of 0. So a script could gain access to anything without a PIN set by using a PIN of 0. I reported this to the OpenSim team a couple of years back where it was addressed privately. I think we're good now with this function.

But keep reports like this coming if you suspect a problem; better to have a false positive than to miss something.