Clickable Culture   Official Research Blog of Phantom Compass
  Secureplay’s Steven Davis on Recent ‘Second Life’ DoS Attacks  
 
 
Posted 2006-10-04 by Tony Walsh
 
 
     
 
Two denial of service attacks have been launched on the virtual world of Second Life in the last two days [1,2], raising questions about the vulnerability of Linden Lab's metaverse and the company's ability to prevent such attacks from occurring in the future. Early on, Second Life was positioned simply as a social online world with built-in content creation tools. These days, the virtual world has been re-positioned as a platform for serious endeavours such as real- and virtual-world business or education. But how seriously can we take a platform that is so easily crippled?

I contacted Steven Davis, CEO of security solutions-provider SecurePlay, and author of the PlayNoEvil security blog for his thoughts on Second Life's apparent vulnerabilities. Although Davis hasn't ever been "under the hood" of Linden Lab's virtual world architecture, he's been watching Second Life's security situation with an expert eye.

Davis believes that Second Life's core security problem is a result of Linden Lab's "real estate centric" view. "They did not consider ownership of assets, creation and duplication of assets as the central function of Second Life, but rather decoration on top of the landscape," he says. "This essential error causes most of the security problems that we see as well as many of the other issues people have with Second Life."

It stands to reason that if Linden Lab could stop DOS attacks from happening, it would have done so already. "If there were easy fixes, they would have been made by now," Davis explains. "There must be inherent weaknesses with the way Second Life works both functionally and administratively that aggravate these problems. For example, if an attack starts, why can't Linden Lab simply globally disable duplication/spawning until the problem is resolved? or stop things from crossing server borders? The inability to do these things to manage problems when they occur, as opposed to generating in-world 'walls' [see: 'Giant Firewall...'] and such speaks to some real 'plumbing' problems."

Davis feels that Second Life "has evolved in many ways that have undermined early security assumptions." When Linden Lab moved from a paid to free account model--where free accounts don't require users to submit any personally-identifying information--many Second Life residents feared an influx of essentially anonymous accounts would lead to an increase in security issues. "The move to weak identification for accounts means that players can act with impunity," Davis says. "Teleporting and many other evolving features have probably added numerous other attack vectors that were not addressed."

So where does Second Life fit, in a security sense, compared to other massively-multiplayer online (MMO) spaces? "By its nature, Second Life is much more vulnerable to in-game denial of service attacks," Davis says. "Any MMO can be attacked via conventional DoS, but since they are all such bandwidth hogs it would take an awful lot of work to knock them out. Most create their own DoS problems due to scalability issues. The closest that I have seen to another in-game DoS is some of the mass protests and suicides that have occured in some of the Chinese MMOs. Second Life's problems stem from the ability to create in-game items. Just like you, I haven't heard much about There in a while and so don't know if there are in-game problems... there. Ryzom has just added the Ryzom Ring which may, or may not, open up these sort of issues. Interesting user created content creates interesting problems!"
 
     
 
   
 
  ... share via email del.icio.us digg bloglines fark reddit newsvine simpy blogmarks magnolia  
  16 Comments  
 
   
 
Comment posted by Scott McMillin
October 4, 2006 @ 2:14 pm
     
 
Interesting stuff, thanks, Tony.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 4, 2006 @ 2:30 pm
     
 
I recall that there was a DoS attack in Eve Online which I was told about by a player then, where a huge number of ships congregated in one place and then released their drones, causing some sort of server crash. I don't know the exact details of that one.

If mass suicides are to be counted as DoS, you could also look at the "Pool's Closed" attacks on Habbo Hotel by people from 4chan, SA, and various other places.
 
     
 
     
   
 
Comment posted by Tony Walsh
October 4, 2006 @ 3:48 pm
     
 
Hmm, now that I've looked up the "Pool's Closed" attacks, I'm wishing I'd hit myself in the nuts with a hammer instead. Some interesting similarities in between these griefers and typical W-HAT shenanigans.
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 4, 2006 @ 4:06 pm
     
 
I'm disturbed by the implication of what Steven Davis is saying about real-estate based worlds as being the core of the problem for its implication on other debates.

These concepts are constantly and furiously debated between immersionists and augmentationists, between worlders and platformers, between "country" or "company" -- that is, is the value of a second life or the Second Life experience itself located in real estate itself, i.e. virtual estate, the square meters of server space, that you own like a website in one sense, but more like 40 acres and a mule, or is the value in content creation and making of clothing, vehicles, etc. for avatars.

The social systems that these centric views spawn are different; one values a meritocracy of sorts or even what I call creator-fascism that says create or die, or that the highest-valued content creators rule the platform with their needs for platform features taking precedent over the needs for the landed, i.e. bells and whistles like flexi prims versus group tool fixes for controlling land.

But I think the basic issue hasn't been understood. The reason people can still replicate grief balls across frontiers is because the Lindens refuse to deprecate that script command. They did briefly; they then caved to lobbying from the IRC channel, i.e. the cadre of scripters, especially very brainy and talented script kiddies, who never met a script they didn't like, and want absolute freedom to script whatever they can script, without consideration of its impact on the quality of life (i.e. many would like to deprecate teleport home scripts to end the awful experience of harsh security orbs, but scripters lobby to keep it because they are absolutist about never deprecating scripts).

That's my understanding of it, which may, of course, be flawed as I don't know the mechanics of scripting. What I do know is that the Lindens *can* deprecate that command but *don't* because every time it is discussed, there's a small but hugely vocal scripting/tekkie lobby that says, "but what about our cool and interesting experiments in organic life". Someone will incite public opinion by showing off the beautiful replicating koi in a Japanese pond, or cite the amazing sim of Svarga with its organic-like life that presumably depends on these scripting functions (I've never understood why it depends on them to replicate *across sim borders*).

There's convenience to be had in news media, vendors with notecards and objects, etc. in being able to send objects across borders. But the real debate about the tradeoff never can seem to be had, because we're not really in a free society.

The Lindens often say they've stopped these replicating attacks and removed the offending object; we often come back the next day and still find the stuff. What's especially troublesome now is that the hackers have figured out how to grab other people's objects, not just the old Linden-made objects from the library that were copyable, so that grief balls, for example, in my name went out (I'm now struggling to delete 60,000 grief balls someone created by grabbing something of mine on "copy" and forcing it to replicate (obviously I know nothing about how to do this) -- which are now returned by irate residents from my lost and found file; the situation has utterly paralyzed my avatar and inventory in world to a standstill and no one can do anything about it).

There were supposed to be grey goo fences -- well, where are they? We could live without organic life experiments at least until they are perfected, couldn't we?
 
     
 
     
   
 
Comment posted by Secureplay
October 4, 2006 @ 5:46 pm
     
 
Prokofy -

I thin we are agreeing violently. I am not addressing this from a philosophical perspective, but from a nuts&bolts;view. Linden Lab seems to have conceptualized Second Life primarily as a real-estate venture. It seems to have focused its design energies on those aspects of the game/world. This has had a serious impact exactly as you describe - they have not put anywhere near enough consideration into assets and scripts and their ownership and control.

Real estate is the DNA of Second Life and Linden Lab, not scripting and assets.

That this is a core conceptual error is the source of many of its problems.

Tony asked me why I thought the security problems that Second Life faces were not going away. The most insidious security problems are conceptual mistakes - my opinion is that Linden Lab's technical model is build on several such errors.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 6:54 am
     
 
Prok, I've said it before, but there isn't any "self-replicate" command in LSL. There is nothing to turn off.

At heart self-replication is just two steps. You make an object which has a script to do the following:

1. rez an object
2. give a copy of that object to the object it's just rezzed

Then you take a copy of the object and put it inside another copy. (This gets around the nesting problem, that eventually you have to rez an object which doesn't have anything to rez.)

In actual fact you don't even need to do that to crash the grid if you're patient enough to put a copy of A inside B, then B inside C, then C inside D etc. So basically as long as objects can contain and rez other objects there is a potential problem, and those are immensely basic functions. You might as well turn off all scripts, which they do when there's an attack.

It's got nothing to do with artificial life; that is just something that people use to illustrate productive uses of self-replication.

What they need to do is fix the holes in the grey goo fence, which was working well until someone figured out a way through it, because that actually targets the specific problem ("rapid or recursive rezzing").
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 5, 2006 @ 7:12 am
     
 
Ordinal,

I'm not claiming there is a "self-replicate" command. While I'm not learned in scripting, I do understand that "give inventory" is at issue. And I guess I'm not afraid of appearing ignorant, and I continue to ask questions about the make-up of the world, because I think that the makers and modifers of it among programmers can be called upon not only to explain themselves, but restrain what they are doing.

I do recall what you wrote as a comment on the piece about the replicating lily:

http://www.secretlair.com/index.php?/clickableculture/entry/rogue_lily_disrupts_second_life_service

If you are saying that "give inventory" is so basic that you couldn't remove it because then nobody would be able to rez or give anything, that's understood. But how is it able to cross borders? It's the "give inventory across sim borders" that's at issue, isn't it?

Or are you saying that it pushes across borders through some other mechanism?

You said on that piece,

"For instance, there are delays on lots of functions, where the script is supposed to sleep for X seconds after using it, and fine, that sort of thing stops a new scripter from writing a loop with llGiveInventory and sending hundreds of notecards a second to everyone in the vicinity. However, by having different scripts that are told by a main script to give an object or rez an object etc, you can get around this quite easily, and in fact many popular and useful objects couldn't work if you couldn't."

Well, again, what are the popular and useful objects? Could we review this?

I realize that I may seem dense and ignorant, but I've learned to keep asking these questions. For example, we heard endlessly that there was just no way we could live without "teleport home" that makes the security orbs so obnoxious, but then eventually we come to find out that the only tiny lobby for this is wargamers who have games-within-games in SL which depend on the idea of killing the avatar and forcing him home AND a tiny lobby of people who made elevators for their homes (in a world where people fly or use teleporters, the handful of operating elevators hardly seem a reason to make the entire world endure the nastiness of security orb functions).

Yes, I realize that it isn't literally creating artificial life and that it in a sense has "nothing to do with artificia; life" but my point was exactly that: that this self-replication is something that people use to illutsrate productive uses of self-replication.

So again, I'd like to challenge this and ask: what are these productive, "popular" and seemingly necessary uses of these functions that we all "can't live without"?

If the fence no longer works and someone found a way through it, sure, you can tackle the fence problem, but again, I want to go back to looking at the wayward goat problem: what items need "rapid or recursive rezzing" so badly that we can't live without them, and therefore can't shut down that function.

And if the answer is, it's "give inventory" in general, which of course is central to a world where everybody gives everybody else stuff in vendors and kiosks, fine, but then I'd like to hear that, and hear why the crossing of borders, and the timer issue can't be fixed then.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 7:52 am
     
 
llGiveInventory is pretty basic to self-replication, as well as vendors, but it's not actually necessary for an effective grid attack anyway, if you have somebody who is prepared to spend an hour putting one object into another object into another object etc etc. You end up with something that isn't truly self-replicating but might as well be.

The fact that you can give inventory across sim borders isn't the reason attacks cross sim borders - it's the replicating objects themselves which move across the borders, just like any object can move to a different sim. I think the lily was just a physical object that was given a shove, I don't know about this one.

So the root functions here seem to me to be letting objects contain other objects, rez those objects, and move between sims. All of those I'm sure you'll agree are pretty essential functions to have. You might also add objects being able to give objects to other objects to that list but it's not essential.

The grey goo fence is supposed to prevent abuses of those functions by targetting objects which rez objects which rez objects, all in a short space of time, and while it does break some nice things and there was a bit of whinging when it came out, in the end people seemed to agree that it was actually a necessary solution and they couldn't think of anything better. I think the *concept* of the grey goo fence is a good one, it targets rezzing that can cause grid crashes and leaves almost all legitimate types of rezzing alone. It's just that it seems to have bugs in the execution, so those need to be patched up.
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 5, 2006 @ 8:26 am
     
 
1. I don't see how stationary objects can be made to move, unless they are physics-enabled or are pushed -- the lilies had physics to drift, as far as I know. How can you push an object beginning to bulge with other objects inside it to the next sim? When objects reach the sim's prim limit, they begin to return to inventory lost and found normally.

2. I don't see how a person, even prepared to sit putting 15,000 objects one into another to fill a sim, can then keep that thing going when the sim itself, being full, will return stuff to inventory.

3. Objects need to contain objects, sure -- that's how vendors and info kiosks and everything works. But do they need to become infinitely nesty matrioshka dolls? Of course not. Can't there be a limit set there, that each object can only endure up to 100 other objects being put inside it. I can't think of a single purpose for putting objects into each other endlessly like matrioshka dolls unless you enjoy puzzles or...grid-crashing.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 8:40 am
     
 
1. Objects can propel themselves via script, whether physical or non-physical. An nonphys object that enters a no-script area will stop moving, since it needs the script to keep calling llSetPos for it to move, but a physical one will carry on coasting along at its previous velocity (there is a bit of air resistance in SL, but not much). My trams do this for instance, they are nonphys objects rezzed by another object, but after they are rezzed they start moving on their own.

2. That's why the things need to spread themselves across sims - otherwise, it will just crash the sim first (though it could also cause problems with the asset server or some other grid-wide server I suppose, or overload the object return function or something).

3. There could be a limit on nesting, yes, that was another thing that I thought of. It's not so much the level of nesting that causes the problem, though, as much as how many times each object then rezzes its contents. Even a three-level nested object, which I've built for perfectly legitimate reasons, can break things quickly. If you put A inside B, then B inside C, and C rezzes copies of B every 0.2 seconds, and B rezzes copies of A every 0.2 seconds, then you get a ridiculous number of As very quickly. The grey goo fence stops that sort of behaviour though, if it's working.
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 5, 2006 @ 9:14 am
     
 
Ordinal,

What is making B rez copies of A every .2 seconds? If an autonomous avatar hasn't himself manually copied it, what is making it copy? What sort of timer or replicator?

Thus, if I put A inside B, and B inside C, there's nothing except an actual script command set up ahead of time to make C keep replicating. Normally, C would sit there until I personally decided to copy it.

Furthermore, only if I wrote into the script originally that it should propel itself. C always stays put where I rez it unless I myself have scripted it to move.

So that's what I'm trying to get at, those two functions that make it move, and make it replicate.

You say there's no self-replicating command, however.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 9:41 am
     
 
Yes, C would have a script which rezzes a B every 0.2 seconds, using the timer() event. Each B would also have a script which rezzes an A every 0.2 seconds. If they wanted to move as well they could quite easily do the same with a timer too. No manual intervention would be required after setting C going in the first place, which could be done by all sorts of means, you wouldn't even have to be online.

The function to rez an object is llRezObject, the same function whether you want to rez a lily, a bullet, a house, a platform, a staircase etc. You can move an nonphysical object with llSetPos; physical ones, you can use llApplyImpulse or llSetForce or a few other functions. None of these are really potential candidates for removal.
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 5, 2006 @ 9:53 am
     
 
Ok, Ordinal, the timer affects the timing.

But what you have done now is isolated for me this function:

llRezObject

Why would you need to set up objects to rez on their own? For what purpose? That's what I'm getting at.

It's one thing when I as an avatar elect to move an item out of my inventory and rez it, or when I elect to use "copy" on it.

What are the "legitimate purposes" of having the object rez *itself*?

That's what seems to me indeed to be a command for self-replication. It seems to me that "llRezObject" *is* the command for self replication.

The command for self-replication is 1) llRezObject, plus 2) timer if 1) contains some kind of thingie in it to react to timing.

So what would be the legitimate purpose of those 2 things combined, and why couldn't you just set the grid up so that it never recognizes orders from when those two things are combined?
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 10:41 am
     
 
They're not really rezzing themselves - you can't use llRezObject to act like, say, an avatar shift-dragging an object. In my above example, A, B and C are all different objects, and even for proper indefinite self-replication, it's not rezzing itself; what it's doing is rezzing an object that is identical except that it does not also contain a copy of itself in its inventory, and then giving it a copy of the incomplete version so that the new version can do the same.

That latter bit isn't terribly clear, I'll try to describe the process... you create a box called "Replicator" and put a script in it which says "when triggered, rez item 'Replicator' and give a copy of item 'Replicator' to the thing I just rezzed". Now, at that stage, "Replicator" doesn't have an item called "Replicator" inside it, so the script can't do either of those things.

Then you take a copy of "Replicator" into your inventory. You open up the one you've already created and drop the copy of "Replicator" that you have in your inventory into *its* inventory.

Now the "Replicator" on the ground - call it Replicator1 - has another item called "Replicator" in its inventory, which doesn't contain any other items, just a script. You trigger Replicator1, which rezzes that item, say as Replicator2, and then gives it a copy of the empty "Replicator". Replicator2 is now effectively identical to Replicator1. You can trigger Replicator2 and it will rez Replicator3, you can trigger Replicator3 and it will rez Replicator4 etc ad infinitum. A grey goo attack works like that except simply being rezzed is the start trigger, and each "Replicator" will rez as many new "Replicator"s and give them a copy of "Replicator" as it can. The only way to prevent this would be to stop objects giving things to other objects, at which point you just have a spammy object that's easier to deal with.

In any case, even manual nesting will work pretty well without there being any inventory giving at all.

Incidentally, the timer example was just one method of repeatedly doing something; there are other events which can act as timers, and in fact you could just put the rezzing command within an infinite loop. Detecting infinite loops even in something like LSL is intractable (see: the Halting Problem).
 
     
 
     
   
 
Comment posted by Prokofy Neva
October 5, 2006 @ 12:15 pm
     
 
Well, I'm not sure I understand all of this, but it seems clear that discussing it can in fact give ideas to copy-cat griefers. I'm for discussing it anyway so that there is a sense of pressure on LL to do something about this. Obviously they have their own internal pressures, but honestly, it's critical that they do something to stop bringing the world to its knees. Otherwise, they can't have a world. It's not viable.

It seems to me that what you're saying ultimately is that there is not an isolated function that one could order to stop, even temporarily, there is only the social problem of the malevolent user of these functions.
 
     
 
     
   
 
Comment posted by Ordinal Malaprop
October 5, 2006 @ 2:30 pm
     
 
The basics of self-replicators are pretty well-known anyway - I'm not saying anything that's not already on the scripting wiki, only it's in a more technical format there.

LL could lock down llRezObject in the event of a grid attack, but that wouldn't solve everything (e.g. particle, object and chat spam) and it seems as if they have trouble locking a specific function anyway - considering the annoyance and the problems that could be caused for existing scripts if some functions work and some don't, it's probably a better idea to just stop scripts completely in emergencies, which is what they have been doing.
 
     
 
     
   
 
 
     
 
     
[ Detailed Search ]
Clickable Conversation
5224 comments
on 4159 entries

Dinozoiks wrote:
Wow! Thanks for that Tony. Just posted a bunch of other tips here... http://www.dino.co.uk/labs/2008/45-tips-when-designing-online-content-for-kids/ Hope it helps someone... Dino...
in Dino Burbidge's '10 Things To Remember When Designing For Kids Online'


yes, many of the free little games are crappy. but as an artist who has recently published free content on the itunes app store,…
in Free iPhone Games Are Awful: Strategy?


I vote for popup radial menus. Highlight a bit of text, the push and hold, Sims-style radial menu pops up with Copy, Paste, etc....
in More iPhone Gestures, Please


Hey Tony! A client of mine is looking to hire an internal Flash game dev team to build at a really cool Flash CCG…
in Dipping Into Toronto's Flash Pool


Yeah, there's a lot of weird common sense things I've noticed they've just omitted from the design. No idea why though....
in More iPhone Gestures, Please


It also bears noting there's no mechanism right now for a developer to offer a free trial for the iPhone; the App Store isn't…
in Free iPhone Games Are Awful: Strategy?


@GeorgeR: It's on my shopping list :) I've heard good things about it as well. And Cro Mag Rally. @andrhia: meh, I don't know…
in Free iPhone Games Are Awful: Strategy?


...you get what you pay for, you know? I actually bought Trism based on early buzz, and it's truly a novel mechanic. I've been…
in Free iPhone Games Are Awful: Strategy?


The only one I've heard good things about is Super Monkey Ball. Have you given that a whirl yet?...
in Free iPhone Games Are Awful: Strategy?


Advance warning: this frivolent comment is NOT RELATED or even worth your time ... But whenever i hear "Collada", i think of that SCTV…
in Electric Sheep Builds Its Own Flock


Clickable Culture Feeds:

RSS 2.0 ATOM 1.0 ALL

Accessibility:

TEXT

Clickable Culture
Copyright (c)1999-2007 in whole or in part Tony Walsh.

Trademarks and copyrights on this page are owned by their respective owners. Comments owned by the Poster. Shop as usual, and avoid panic buying.