> On 23 Jul 2017, at 21:16, Cinder Roxley <[email protected]
> <mailto:[email protected]>> wrote:
>
> On July 23, 2017 at 2:44:01 PM, Haravikk ([email protected]
> <mailto:[email protected]>) 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 😃
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
