[Opensim-dev] Protecting Inventory From Malicious Regions

[Haravikk]

> On 23 Jul 2017, at 21:16, Cinder Roxley <cinder at alchemyviewer.org <mailto:cinder at alchemyviewer.org>> wrote:
> 
> On July 23, 2017 at 2:44:01 PM, Haravikk (opensim at haravikk.me <mailto:opensim at haravikk.me>) wrote:
>> 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 <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 😉)
> 
> Interesting idea, but not all the messages you’re talking about come directly from the viewer. UpdateCreateInventoryItem, for example, is sim -> data server and SaveAssetToInventory should never be accessible to the viewer.
> 
Since I'm new to the code I'm not familiar with everything yet, but for signing to work this may not necessarily be an issue; no matter what the calls actually are they must surely be invoked in response to something that the viewer actually requested, the aim is therefore to define those possible commands so that they can be signed and passed on where necessary. The actual requests themselves don't need to be signed in full, just the part identifying what they will ask the inventory server to do.
> Some of the packets are already pretty dense as well and can’t afford to have a signature attached to them.
> 
This actually ties in; the signatures don't necessarily need to be on the messages themselves, they could for example be a separate messaging protocol to keep things as separate as possible (and to make SL compatibility easier). For example, say I want to delete an item from my inventory, my viewer could create some kind of "consent" message describing the action (inventory/delete/<UUID>) before signing it with my certificate; now, when my viewer sends the request to do this, so long as the simulator also has the signed consent it can pass that along to the inventory server to confirm it was given permission to do it.

Of course doing it in separate messages is more awkward, but it's doable. Basically a supported viewer would send consent for an action in advance of sending the actual request, at which point the simulator caches this, and when the request comes in it looks for the consent and passes it along as necessary. There are a few advantages to using a separate message entirely, which is that it avoids touching the main messaging protocol, and should avoid issues with viewers/sims that don't support signing, as they simply won't send/won't respond to (or will reject) the consent messages.

Basically we'd need to come up with a list of all the actions that require signed consent, so for example under inventory we'd have all the other operations for taking something into inventory, copying etc. etc. Plus we could do the same for other areas where region trustworthiness is a problem; pretty much anything that involves passing messages through the region to some grid service.
> (I also believe you mean asymmetric key, not asynchronous.)
> 

You're absolutely right; while I promise you English is 100% my first language, it's not always obviously the case 😃
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20170724/edf28134/attachment.html>