[sldev] Decentralised architectures, Mono, sandboxing and exploits

Zha Ewry zha.ewry at gmail.com
Thu Sep 27 12:16:28 PDT 2007


I think that, in general, this is a bound checking issue, writ large. Right
now, SL has a closed world assumption which lets you avoid worrying about
these sorts of issues, or at least worry less about them.

Once we have a range of land simulations and asset stores and clients,
defensive programming  will be called for. An asset, unless it is in some
way signed as trusted, needs to be validated as something that this
particular wants to process and rez. It may be a matter of some specific
parameters, it may be a matter of whether the sim supports a specific
feature. (A scripting language, a prim format etc.) For added sport, please
note that it will get worse, even inside SL, once het grid fully deploys.

We will need ways of marking what capabilities Sims have, what requirements
objects have.. and good sim implementations, will check such things. The
Architecture, need only make sure it allows for such markup, where it is
needed, and driven by use cases. Sim implementors, need to then take
advantage of such features, as they see fit.

We need to be very aware of the line between architecture, and how big
components interact, and implementation, and how people build things which
meet the interface contracts. of the architecture.

- Zha



On 9/27/07, Matthew Dowd <matthew.dowd at hotmail.co.uk> wrote:
>
>
> I've not caught up with all the discussions over the new architectures for
> allowing third party sims etc. so this may have been raised before?
>
> However, the news that Mono is working for scripts (at least on some test
> sims), started me thinking about security issues raised by opening up the
> grid beyond the whole permissions debate.
>
> At the moment the sim server itself guards against pathological scripts
> and prims being uploaded/created. For instance in the case of a script the
> compilation engine will hopefully catch and prevent exploits.
>
> However, with an open sim, I could create a modified sim server which
> would allow me to manipulate a compiled mono script directly (are there are
> probably lots of tools out there for decompiling and modifying mono/.Net
> bytecode directly) - this could lead to possible exploits such as modifying
> the script to call some internal sim code normally not accessible by
> scripts. This script could be moved to other sims to hack or disrupt them -
> unless there is a very strong sandbox around the Mono script interpreter
> which prevented this - has this been built into the current mono
> implementation?
>
> Alternatively, I could modify the bytecode to include a tight loop which
> could disrupt the script interpret and heavily lag a sim - are there
> protections for this.
>
> There are also issues with prims - at present the sim server code prevents
> me creating a huge prim, in an open grid the sim code could be modified to
> allow this and then huge prims moved onto other sims. OK huge prims are a
> major issue since there are enough copiable ones in world already that you
> don't need to go to such lengths to create them. However, could you create
> disruptive prims by relaxing the sim server code. e.g. a prim with a
> gigabyte texture - what effect would that have if rezzed on a sim not
> expecting such a large texture? Do we need sanity checks on anything rezzed
> in a sim in an open sim evironment to prevent this?
>
> Matthew
> _________________________________________________________________
> The next generation of MSN Hotmail has arrived - Windows Live Hotmail
> http://www.newhotmail.co.uk_______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070927/4f7b7499/attachment.htm


More information about the SLDev mailing list