Home

G-Men Called on W-Hats for WMVD

One of the cool things about Second Life is that players can create new kinds of objects, by writing small programs in a special scripting language to describe how the objects should behave, and then launching objects into the world.

Things got really out of hand when the W-Hats created a doomsday device. It looked like a harmless little orb, but it was programmed to make copies of itself, repeatedly. The single object split into two. Then each of those split, and there were four. Then eight, and sixteen, and so on to infinity.

A highly amusing story this is.

I guess the correct term for this kind of thing is The law of unintended DSL consequences.

Please share similar stories, if you got them.

By Ehud Lamm at 2005-12-17 13:30 | DSL | Fun | other blogs | 17443 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Wouldn't the problem be solved by an antivirus object?

Wouldn't the problem be solved by an antivirus object that deleted the "replicating harmless little orbs" on sight?

By Achilleas Margaritis at Sun, 2005-12-18 11:54 | login or register to post comments

No

No more than antivirus software has eliminated viri and DDoS attacks elsewhere.

By Paul Snively at Sun, 2005-12-18 18:54 | login or register to post comments

This was possible in lambdamoo too

On lambda, it was quite easy to get a programming bit. The thing is, (and I verified this not on the main lambdamoo install itself, but on my own copy of the lambdamoo server + lambdacore) it's very easy to write a one-line quine which, when typed in as an eval (i.e. what happens when you began a line with ";") will fork off multiple copies of itself, each of which will fork off other copies of themselves, etc. Note that there's no object with code on it that is running at this point, so there's no place that wizards can remove code from, assuming they notice things in time.

This brings the server to a screeching halt, requiring a kill -9 on the unix side. Within about 10 or 20 seconds, the resources get so sucked up that none of the standard lambdamoo administrative options (such as removing the programmer bit from the programmer in question) will work. The server is effectively hosed.

Now, I heard a rumor that there was some relatively common object with a known eval hole in it - since the user the eval'ed code ran as didn't own anything important, and since programmer bits weren't all that hard to come by anyway, I understand it wasn't considered a priority. However, with the ability to have guests destroy the server process at will...

All of which is to say that there's little new under the sun.

By fizbin at Sun, 2005-12-18 15:07 | login or register to post comments

forkbombs

A simple task limit put into the task scheduler put a stop to forkbombs on MOO long ago. Resource exhaustion by building up huge lists or strings is still possible however (I've done it accidentally with runaway recursion). Although MOO was designed to run mutually hostile code, the server always assumed some trust in its programmers to not DOS it. It's virtually impossible to close off all the avenues for DOS attacks such as this without requiring some very expensive process accounting overhead for all tasks.

Runaway object creation in LambdaMOO was virtually impossible due to the quota system. I should imagine Second Life also had such a system, but that the Doomsday Device hackers merely found a loophole.

By Chuck Adams at Mon, 2005-12-19 17:40 | login or register to post comments

Cooperation vs. Vulnerability

Chuck Adams: Although MOO was designed to run mutually hostile code...

It was? In what sense? One of my primary frustrations with LambdaMOO was that from an ownership transfer POV, you could hardly do anything interesting with it. For example, I wanted to create a "vending machine" object that would serve as a factory of other objects, these other objects being created from quota held by the user of the vending machine rather than my own quota. I couldn't do it, and what's worse, when I inquired as to why I couldn't, the response was along the lines of "you're crazy to want to."

So basically, LambdaMOO, at least, lacked the ability to express some potentially interesting "patterns of cooperation." That is, it lacked a rights transfer mechanism that all programmers could use. There was, as I recall, a very simple "ownership transfer" object somewhere in the world, but you couldn't code, e.g. a digital cash protocol in LambdaMOO. So there wasn't much to be vulnerable to other than DOS attacks, and yes, forkbombs and their ilk were reasonably well-controlled.

But when you look at an environment like Second Life, where part of the point is to serve as a platform for the construction and dissemination of digital goods and services (games within the game, skins, models, snippets of code, other objects in the world...) and even to go one step farther and make the connection between the virtual economy and the real economy explicit, you need a rights transfer facility; just limiting object construction isn't sufficient. I should be able to build a vending machine (and its users should understand that when they use it, they're exchanging value for value).

This seems to me to be a precondition for exposing yourself to interesting (as opposed to trivial) vulnerabilities in such an environment, and is why object-capability security is the right paradigm for environments that allow such rich interactions. Where I think this becomes a language design issue, to attempt to bring this home, is in the design decisions that you can see reflected in languages such as E and Flow Caml, which take notions of rich cooperation while limiting vulnerability vastly more seriously than any other languages I'm familiar with, including the various MOO languages and LSL.

By Paul Snively at Mon, 2005-12-19 20:36 | login or register to post comments

Vending machines in MOO

Your vending machine problem was one with the stock LambdaCore, not the MOO language or runtime. It's extremely trivial to create a vending machine that would effectively @grant objects it created to the vendee, and in fact a few wizard-owned objects did exactly that. Generalizing this to an API is an exercise for the user.

Granted, MOO is a rather uninteresting language, VM, and even security model, but it more than sufficed for the chat MUDs of its day. E's solution as given in their own use case papers on POLA appears to be a living hell of permission pop-up dialogs. We've all seen the end to where that path leads.

By Chuck Adams at Thu, 2006-01-05 19:11 | login or register to post comments

All the Interesting Exercises are Left to the Reader!

Chuck Adams: Your vending machine problem was one with the stock LambdaCore, not the MOO language or runtime. It's extremely trivial to create a vending machine that would effectively @grant objects it created to the vendee, and in fact a few wizard-owned objects did exactly that. Generalizing this to an API is an exercise for the user.

I remain unconvinced that LambdaMOO's language and/or security model would actually support rights transfer in the sense of object-capability security in the absence of a demonstration, and since LambdaCore was all I had to work with, the point seems moot to me.

Chuck Adams: E's solution as given in their own use case papers on POLA appears to be a living hell of permission pop-up dialogs. We've all seen the end to where that path leads.

From this I can only infer that you haven't actually used CapDesk, the DarpaBrowser, Den, or really anything else written in E: the papers are quite careful to point out that the "living hell of permission pop-up dialogs" is what you get from the existing broken ACL-based security paradigm, as opposed to what you get from an object-capability system. Secure Interaction Design is an excellent launching-off point to acquire more information. The simple fact of the matter is that there hasn't been a widespread deployment of any POLA system, so claims such as "We've all seen the end to where that path leads" are wildly inappropriate.

Update: An even better launching-off point might be Introduction to Capability Security, which addresses "permission hell" explicitly.

By Paul Snively at Thu, 2006-01-05 20:29 | login or register to post comments

Not Merely Predictable...

...but predicted. I first really got interested in "digital rights," in the sense of Nick Szabo's contracts with bearer, when I was a programmer on LambdaMOO and saw how horribly broken their quota-management system was. As Ed Felten has pointed out:
The crux of this issue is the status of the in-world (i.e., in the virtual world) economy... Is in-world money just Monopoly money, or is it in some sense real money?

The only sensible answer is that it’s real money if it’s readily exchangeable for real-world currency. If you can trade in-world gold pieces for U.S. dollars (or Euros, etc.), and vice versa, then in-world gold is real money, and the in-world economy is a real economy...

Experience seems to show that any sufficiently popular in-world currency will become exchangeable for real money, whether the world-designer likes it or not.

That is, you need to design your virtual economy as if your virtual environment were a bank—because it is.

Some of the vulnerabilities in Second Life exist because LSL is not an object-capability language. Others, such as the one described in the article the original post refers to, exist because Second Life does not implement Nick Szabo's scarce objects. I anxiously await the day in which developers of MMORPGs learn:

and build a much richer version of the Den Project.
By Paul Snively at Sun, 2005-12-18 18:41 | login or register to post comments