Hypergrid Security

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
<br />
<br />
= Configuration settings =
== Simulator (StandaloneCommon.ini or Robust.HG.ini/Robust.ini) ==
=== [GridService] ===
==== HypergridLinker ====
Controls whether hypergrid links can be made to external installations.  Default is false.
If this is true then GatekeeperURI must also be set either here or in the [Hypergrid] section.
==== AllowHypergridMapSearch ====
Governs whether the simulator will resolve Hypergrid addresses entered in the map.
= Discussion =
= Discussion =

Revision as of 10:01, 7 May 2014



There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

Malicious Clients


Everyone knows about the infamous CopyBot. Using libraries such as LibSL (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects all servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

Web Clients

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSimulator has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

Malicious Hosts

Actively Malicious Hosts

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

  • The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
  • Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described here.


A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as piracy. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

Personal tools
About This Wiki