I’m a security researcher. I find bugs in software, they get fixed. I write exploits, they give me a shell. It’s more or less always the same and it gets kind of boring. But there was one exploit I helped write back in 2007 that was a little different. This is the story of that exploit.
Second Life is a virtual world with many million participants created by Linden Labs. Your digital representation in this world is called an avatar. You can make your avatar wander around, buy houses, design clothes, get married, whatever you like. Think of it as World of Warcraft without the weapons. There are a few interesting features of Second Life that make it interesting from a security perspective. The currency used in the virtual world, Linden dollars, can be exchanged for real currency in a fully supported way. The exchange rate is something on the order of 270 L$ for 1 USD$. Therefore, if you could exploit another player’s client, you could potentially cash out their Linden dollars for real money.
Another interesting feature is that it supports the ability to create objects in the world. You can create shirts, cars, whatever you like. Finally, like most virtual worlds, Second Life is designed to be as immersive as possible. Your avatar can hear sounds and music, you can talk to other players, you can watch videos. It makes for an enjoyable experience, but from a security perspective, it means the game client must be prepared to parse a variety of different kinds of data.
The great thing about this is that instead of an exploit being an email attachment, or malformed web page, the exploit may take a physical presence inside the virtual world. The exploit may be something that another avatar whispers to you or an object they hand you or it may be a particular place in the virtual world. Unlike most typical computer attacks, your avatar will be able to see and interact with the “exploit”.
It turns out that Second Life uses QuickTime Player to process its multimedia. When I started looking into virtual world exploits, with the help of Dino Dai Zovi, there was a stack buffer overflow in QuickTime Player that had been discovered by Krystian Kloskowski but had not yet been patched. In Second Life it is possible to embed images and video onto objects. (See Figure 1.) 
We embedded a vulnerable file onto a small pink cube and placed it onto a track of land we owned. No matter where the cube was, if a victim walked onto the land and had multimedia enabled (recommended but not required), they would be exploited. The cube could be inside a building, hovering in the air, or even under the ground, and the result was the same.
Before I fully understood this, I had built a virtual laboratory building to conduct my experiments so that innocent passersby would be accidentally exploited. In retrospect, this precaution was funny, but ineffective.
The good news about this exploit was that you couldn’t take the “exploit” to other parts of the virtual world. The multimedia is associated with the piece of land and not the object itself. So you couldn’t just litter Second Life with little exploit cubes. The bad news was that due to a quirk in the way the virtual world was architected, the malicious file was downloaded straight from the attacker to the victim without going through the Second Life servers. This means the Linden Labs servers could not filter the malicious content and also that the attacker could selectively deliver the exploit to some clients but not all clients. For example, the attacker could choose not to exploit Linden Lab employees!
So we had a dangerous small exploit box that could take control of player’s game clients. At this point, we could make it do the same thing typical exploits do, namely, install malware, upload documents, etc. But, having code running inside the game client allows us to do something a little more fun. Namely, we could make the victim’s avatar perform actions in the virtual world.
Technologically, this wasn’t easy. We had to clean up the stack, get the code running in the main event loop, fix up some global variables, etc. But eventually we had the exploit such that it would allow us to control the victim’s avatar and still allow the player to control their avatar and have no idea anything had happened. You could do all sorts of fun and devious things with the exploit payload. The one we demonstrated had the victim give us 12 L$ and then shout to the world “I’ve been hacked.” (See https://www.youtube.com/watch?v=RaCo4USXd5Y&feature=player_embedded.)
Of course, we could have had the victim give us all their money or we could have had the victim run around taking their clothes off or whatever we wanted. That is the nature of arbitrary code execution. If we were a little more evil, we could have maxed out the credit card the player had associated with the account into Linden dollars before stealing them.
In response, the Linden Labs engineers were generally good-natured about this discovery and even showed up in Second Life to watch the demo live that we gave at Shmoocon in 2008. (See Figure 2.)
While most computer users have been taught basic computer security skills, such as not opening attachments from untrusted sources and not following links in emails, these lessons become worthless when they immerse themselves in a virtual world. The very essence of the virtual world experience means the client program will have to process a large amount of data, much of it provided from other users. If virtual worlds become more popular, exploits such as this will likely become more prevalent.
Charlie Miller is a principal security analyst at Independent Security Evaluators.
This is the third in an occasional series of guest posts by security
researchers, focusing on their favorite or most interesting piece of
research. You can read the previous posts by Robert Hansen and Ivan Arce.
