[Opensim-dev] Protecting Inventory From Malicious Regions

[Haravikk]

While reading about the Hypergrid I stumbled upon the following wiki page, detailing ideas on how to protect against malicious regions screwing with an avatar's inventory:
http://opensimulator.org/wiki/Hypergrid_Inventory_Access

I wanted to ask what the state of this is; the last real edit was 2009 so perhaps it's not an issue anymore? However I couldn't find anything obvious showing that the issue was ever resolved, or if trust of a hyper grid region remains a crucial factor (i.e- is following a hyper grid link you don't trust still a bad idea)?


I just wanted to point out that there is I believe a better solution than those proposed for protecting against this issue; basically, every user account in a hyper grid enabled setup would be give a certificate (asynchronous key), which would be sent to (or fetched by) a compatible viewer during login. Such viewers will then use this key to sign all inventory related requests that they make, thus when a region passes the request along to their inventory server, the inventory server can confirm that the request was not tampered with before carrying out it.

This would make it impossible for a region to send a request to do anything that the user did not specifically ask it to do; so in the example of worst-case example of a malicious simulator downloading a user's entire inventory then wiping it, it would be impossible without the user actually requesting (and thus generating signed requests for) those specific actions.

The downside of this solution is that it would take time to propagate as inventory servers would need to be upgraded with the new key-handling version, and users would need to start using viewers that support the key-handling as well. However, once this is sufficiently common it could simply be made the default (i.e- unsigned requests are always rejected) and the hyper grid would be safe from this form of abuse. There are likely other areas where this could be provided to give the same kind of protection.


Also, apologies if it seems like I'm raising lots of separate issues; a key theme that I'm interested in are issues of trust in security, so things like this jump out and me, and it's an area where I have a reasonable amount of experience (I wrote an implementation of AES in LSL just to make my services more secure 😉)