• United States



Contributing writer

Are metaverse pioneers making the same old security mistakes?

Feb 23, 20158 mins
Application SecurityData and Information SecuritySecurity

History repeats itself when it comes to development mistakes in the metaverse

Ask security pros what they would change about the Internet if they could go back in time knowing what they know now, and most can point to a list of mistakes we could have avoided.

But according to some experts, we’re still making the same mistakes today, with the development of the 3D virtual reality metaverse.

Today, most applications of virtual reality are walled gardens, training or simulation worlds run behind corporate firewalls, games, or marketing experiences.

Avatars can’t teleport from one to another, and can’t send messages or content from one to another, so security is not a priority.

But there are also virtual worlds built on top of open source software, and they do allow avatars to travel, and content to move between worlds. But the developers of these platforms are academics, hobbyists, and volunteers much like the ones who built the early Web — and, critics say, are similarly disinclined to worry about security.

Take, for example, OpenSimulator, which currently powers more than 300 public worlds and thousands of private ones with a total land area estimated at around 15,000 square kilometers, or just a little bigger than the state of Connecticut. OpenSim allows anyone to easily and cheaply set up a virtual world accessible via the Oculus Rift.

One of those worlds, MOSES, is owned by the U.S. Army, and the lack of built-in security is already creating problems.

“Security is kind of a dry subject,” said Douglas Maxwell, science and technology manager at the U.S. Army’s Simulation & Training Technology Center. “People really don’t care about it unless they’re the ones compromised.”

For Maxwell, the three biggest issues are authentication, content protection and secure communications.


Today, by default, OpenSim worlds and most other virtual reality environments rely on a user name and password to authenticate local residents. Some require email confirmation before creating accounts. A very small number go beyond that.

But when they allow teleports in and out, they rely on the partner worlds for authentication. In other words, in the connected OpenSim metaverse, authentication devolves to that of the lowest denominator.

This is because virtual worlds originally started out either as gaming platforms, said Maxwell, or social worlds like Linden Lab’s Second Life.

“People who are using them for entertainment are fully entitled to pick a pseudonym, to make up any character they want and escape,” he said. “But inside the enterprise, identity is critical. In the absence of seeing someone face to face, we need to have an assurance through some sort of accreditation mechanism that that is really me.”

Social worlds and gaming worlds based on OpenSim don’t care as much about identity, he said.

“The only thing they care about is tying it to a payment system, so they’ll leaving the authentication up to PayPal,” he said. “But it’s a separate system, not baked within the virtual world.”

Content protection

On the Web, and on the Internet in general, content protection has long been a hopeless cause. Text, photographs, sound files and videos can be easily copied and passed around. The ability to see a site’s HTML code is built right into the browser.

OpenSim actually has a higher level of built-in content protection than the Web. It duplicated Second Life’s permissions system, which specifies whether particular items can be copied, modified, or transferred. But the system is by no means bullet-proof.

In particular, the hypergrid network that connects OpenSim worlds and allows avatars, communications and content to travel between them can also be used to transport stolen virtual goods.

“I don’t think the hypergrid should be used by anybody, unless they just don’t care about the content,” said Maxwell.

Content protection could have been built into the Web — and the hypergrid — from the start, said Maxwell, but people just weren’t thinking about it.

“Intellectual property is protected quite frequently through digital signatures,” he said. “In the course of my job, I sign legal documents using my common access card that the military issued me as a proxy for my real signature.”

And, on the Web, financial information is protected as well, he said, protected enough for online financial services and commerce sites to flourish.

But content protection hasn’t been universally welcomed online, even when technically feasible.

“Consumers have unanimously voted no to DRM-ed music, which in reality is exactly the same as certificates for content,” said Geir Nøklebye, owner of the Xmir Grid, an OpenSim virtual world based in Norway. “Besides, it is very complicated and costly to manage.”

Secure communications

By default, Internet traffic is all in the clear.

So are communications between OpenSim avatars, as are communications between avatars and OpenSim world servers, and communications between different servers.

On the Web, encryption was bolted on later — but it is not yet available in OpenSim.

“There needs to be a way to ensure that communications are private,” said Maxwell. Even something as simple as fetching an item from inventory could be valuable information to an enemy.

In the case of training simulations, for example, it could allow foreign powers to figure out how soldiers are trained, which could give them an advantage in the field, he said.

“I do not want the enemy to listen in and learn our tactics,” he said.

In the case of corporate worlds, it could provide hackers with insights that they could use for social engineering.

Architectural and coding errors

But OpenSim isn’t just repeating the big mistakes of the early Internet, but many of the smaller ones, as well.

“At the time of OpenSim’s creation, it was not that complicated to predict a couple of hacking approaches that could be used in OpenSim like they used to be on the Web,” said Olivier van Helden, Web developer and owner of the Belgium-based Speculoos OpenSim world.

For example, he said, OpenSim stores executables, libraries, preferences and data in the same place, and shares access permissions across everything.

“You could — as I do — keep all these files in different places,” he said. “But it requires additional work to sort it out, make scripts to read the preferences in the right order and force the log, stores and caches directories locations.”

In addition, large OpenSim worlds typically use multiple servers, one for centralized services such as user inventories, and the rest to run individual regions or groups of regions.

“Many aspects of the security can be set on the [central] grid server, but overridden on the [region] simulators,” he said.

This is a security problem for grids that allow third-party region connections.

“While many experienced Webmasters could customize their OpenSim installation to make it really secure, the standard, out of the box configuration is not secure,” he said. “And that makes as many security holes as the number of inexperienced simulator managers.”

The Linden legacy

One obstacle that OpenSim faces when considering encryption, authentication, or additional content protection is that for most of its history OpenSim hasn’t had its own viewers, but has piggy backed on Linden Lab. In fact, even today, almost all users enter OpenSim through Second Life-compatible viewers.

“We use Linden Lab protocols, and that restricts what we can do,” said Justin Clark-Casey, OpenSim core developer and president of the Overte Foundation that oversees OpenSim licensing issues. Clark-Casey’s work for OpenSim is on a volunteer basis — during the day, he’s a freelance developer working on enterprise virtual worlds projects.

“In a normal Linden Lab situation, there’s no need for that security,” he said. Second Life is a walled garden, and all regions and central services are run on Linden Lab’s own servers.

Despite that, he said, OpenSim developers do bear security in mind and are doing their best as they go along, he said.

“I look at every commit that comes in to check for security problems, and there’s the idea taht many eyes make all bugs shallow,” he added. “But then again, you had the Heartbleed bug… and OpenSim has been growing so organically, with code from so many people over the years.”

The longer it goes, the harder it is to fix

But adding in authentication, encryption and content protection now could break compatibility with the viewers, and with previous versions of OpenSim.

“I think that’s why OpenSimulator developers have been so reluctant to address security,” said Maxwell. “They know the plumbing has to be changed. I believe we’re in this mess mostly because its inconvenient, and people want to go the path of least resistance.”

But it’s not too late to change things, he said.

“It’s time to put on the breaks and say, ‘Stop everybody, we have the rethink the way we do this’,” he said.

Maxwell himself is working to add encryption and other security features to the core of OpenSim, and will make the fixes public, but he doesn’t know whether it will be adopted by the wider community.

“If someone decides to adopt it, they can advertise that they have military-grade security in their grid,” he said.

Adding security in later is harder, and not as effective, said Bruce Schneier, a well-known authority on security and CTO at Cambridge, Mass.-based Resilient Systems, Inc.

“If there’s anything we’ve learned, it’s that adding security at the end is a lousy strategy,” he said.

OpenSim’s Clark-Casey disagrees.

“I know there’s a mantra that you have to have security in front the start or it’s broken forever,” he said. “I don’t believe that. But, then again, I’m not a security expert.”