Protecting Inventory From Malicious Regions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 😉)
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Protecting Inventory From Malicious Regions

Cinder Roxley
On July 23, 2017 at 2:44:01 PM, Haravikk ([hidden email]) 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

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. Some of the packets are already pretty dense as well and can’t afford to have a signature attached to them. (I also believe you mean asymmetric key, not asynchronous.)


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Protecting Inventory From Malicious Regions

Haravikk

On 23 Jul 2017, at 21:16, Cinder Roxley <[hidden email]> wrote:

On July 23, 2017 at 2:44:01 PM, Haravikk ([hidden email]) 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

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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Protecting Inventory From Malicious Regions

Michel Beauregard
There is always a delicate balance between security and freedom.

I am not sure if the following is a good link to check  .
Anyway  If not helpful  simply disregard :

 
GiMiSa




_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Protecting Inventory From Malicious Regions

Haravikk

On 24 Jul 2017, at 13:14, Michel Beauregard <[hidden email]> wrote:

There is always a delicate balance between security and freedom.

True, but the idea behind this proposal is improve security without having to sacrifice any freedom at all; the intent is to establish trust, or rather eliminate the need to trust a region at all (at least when it comes to any kind of permanent damage).


Basically the threat posed by a malicious region is the same as any man-in-the-middle attack, whereby the region is expected to pass along a message from the user's viewer to one or more grid services such as the inventory system. A malicious region can change those requests, or even create requests of its own that do something nasty. By signing the requests (or some related message) in the viewer however it becomes impossible for the region to change that message without causing the grid service to refuse it. This way at most all a malicious region could then do is refuse to pass along the messages.

So the only freedom that would be infringed is the freedom for a malicious region to ruin your inventory, which I think is a fair trade 😉

The only really downside is that (on top of the work required to actually implement it) you'd have to wait for grids, sims and viewers to be updated before the feature could be transitioned to a requirement, as until then it'd need to be optional to avoid breaking everything.

I am not sure if the following is a good link to check  .
Anyway  If not helpful  simply disregard :


This is interesting, but I'm not sure if it solves any similar problems; it looks like it still relies on having a secure LAN with the sims and grid services on it, I'll take a look in more detail but I think it's mostly focused on avoiding external threats and sandboxing some of the processes, rather than rogue simulators.



There is one problem area I've thought of that signing consent may not protect against; this is when handling attachments. Since these are rezzed within a region, and logging out or teleporting away would need to give consent to save your attachment(s) it's still possible for some damage to be done, for example deleting the contents of your attachments, changing the colours etc. so that they're saved to inventory in a ruined form. The damage would be limited only to attachments you're wearing though, which is some consolation.

Not quite sure what the solution to that would be, as simulators need these capabilities in order for scripts to work. It's possible this would need to be addressed as a separate issue, but I have some ideas:

  1. Script Capabilities: Basic idea is that scripts would somehow carry a list of capabilities, e.g- change colour, remove prim inventory etc., possibly detected at compile time and attached automatically. When the user arrives in a region they'd provide consent for these capabilities on the relevant attachments only. This means for example that if an attachment can only change colour, then a malicious region couldn't do anything else to it or else when the object is saved it would be detected. Problem with this is it would require the inventory server to process attachments and compare them to the old version, which is pretty overkill, it would also offer no protection for attachments where the scripts take advantage of a wide range of capabilities (as this means the malicious region would have them as well).
    1. Semi-automatic: A variation of this could be to allow objects to be tagged with some kind of locking method. For example, if a scripted object should only change when touched by the owner, then it could be locked to owner touch only. Thus any attempt to change an object without it first being touched by its owner would fail. This idea is similar to how anti-popup systems work in browsers (a site can't open a new window unless the user did something to trigger it). An advantage of this method is that the viewer can keep track of whether the attachment was expected to change, and thus only issue consent to save for those that did, which limits the scope for damage down from all attachments to only those whose requirements were met. Disadvantage of course is that attachments would need to be locked in the correct way (or at all) which means all existing attachments would be unaffected, though it may be possible to do it automatically based upon the events that each script has (is it possible to detect every event that a script supports?)
  2. Rollback: Probably the simplest idea is that the inventory server could keep track of attachment versions over time, allowing the user to potentially roll-back to an older version of the attachment in case something is damaged. This could also be done for no-copy items (since they don't leave a copy behind when you rez them), so may be worth doing regardless.
  3. Client-Side Attachments: Instead of attachments being sent to regions, they'd be hosted by the viewer of the avatar that's wearing them, this means that any scripts would run locally on the viewer, and thus all changes to the attachments would originate within the viewer as well, with the region just maintaining a copy of the actual prims that it can sync with changes from the viewer, and pass on to other agents (so they can still see your attachments). The main disadvantage of this that script byte code would end up in the viewer, which is a huge breach; it might be fine for specific scripts intended to run on the client, but probably rules this option out.
  4. Off-Sim Attachments: This idea is similar to client-side attachments, but essentially the idea is that a grid would somehow designate simulators for use as attachment "hubs"; instead of having an avatar's attachments run on the regions they visit, their attachments would instead run within these hubs. Regions would instead only see a copy of the prims that make up the attachment, receive updates of any changes, and pass in any events and such that the attachments might respond to. The attachments meanwhile would think they're on the destination region, even though they're not. The advantages of this approach is that changes to an attachment can only either come from the attachment hub (as a result of a script) or from the user's viewer (as a result of them editing the attachment), meaning that in the latter case a signed consent can still be used to ensure the region can only do as requested. In terms of hyper-grids in particular this option effectively puts attachments in a similar wrapper to everything else, since the attachments would never leave the grid where the inventory server resides. There are several disadvantages though; first is complexity, there is also potential lag since updates need to be transmitted, and the hubs need to somehow manage load. Otherwise, the big roadblock is that grids would need to somehow allocate (and have available) simulators for this purpose, though for hyper-grid use the simulator where your attachments reside could simply be the last one you were in before you left the grid. This could be nifty for people who user the hyper-grid from their own standalone personal grid, since your attachments would never leave your control, and any scripts within them could run as fast as you like (though it would still be up to the target region how quickly any updates take effect).

Option 4 is my favourite, but also by far the most complex; with that in mind I'd probably lean towards option 2 in the short-term, as it provides a safety net for damaged attachments, with a view to something more complete in future. It's something that would also be very useful to have anyway, as it could also be used to recover from irreparable damage done a no-copy object by restoring it to the state it was in before you rezzed it.

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...