The redzone was some third-party service in Second Life that allowed people to correlate between avatars and IP addresses. A while back, a great case was made out of it, and while the fluff was bigger than the punch, the main reason for creating a redzone service was to impose restrictions on users universally (all the alts included). This is not innovative in any way, in fact some MMOs such as GuildWars implement this feature server-side: once a player is ignored (muted in Second Life terminology), the ignore is set on the whole account such that rolling a new character (avatar in Second Life terminology) will not override that ignore.
The benefit of something like this is arguable both ways, however the triviality of how easy it is to accomplish such a correlation does not warrant leaving it up to obscurity on Linden's behalf.
This was sent to as as contract work long ago, however we turned it down, made it anyway, shut it down and we're now explaining the principles here.
Second Life (and OpenSim) is a service that relies heavily on HTTP for transmitting data in and out of the world. Some of the communication between the avatar and the outside world is performed through Linden servers, whilst other communication is performed at the viewer level - between the viewer and the outside world.
The general distinction is made by scripts that reside within the virtual world:
In the first case, it is impossible to use LSL to gather TCP-level identifying information from an avatar in-world. However, a combination of the first and second means of communication can be easily implemented in order to harvest avatars and their connecting IPs.
Two methods are explained that could easily be implemented - we mean easy from the perspective of the programming required, perhaps a fair share of struggle with testing and optimizing them.
A boilerplate scenario would be to agree with several (or just very popular) simulator owners to harvest data for them. The set-up would involve parcelling the landing point - perhaps in parcels with either a media-on-a-prim primitive as the base or a shoutcast address for that small land parcel.
When the avatar teleports to that simulator, they get directed to the landing point, their viewer connects to a shoutcast or a website address that uses plain PHP (or other) methods to determine the IP and, additionally, the primitive sends their avatar name along with it. This method has its limitations because an avatar may reject to play the media and a different incoming agent may mix-up what IP belongs to whom.
Nevertheless, the specifics could be worked out in order to be precise enough. Since we assumed that we will be doing this on very popular simulators, there will most likely be revisits of the same avatars, so that the collected data could be gradually refined and made stronger in time.
Perhaps a more feasible solution would be to create objects that have hidden scripts in them that load a webpage on a hidden primitive - or perhaps, it could be disguised as the functionality of the object itself. These could then be sold as freebies over marketplace and once rezzed would harvest the IP and avatar name of the buyer (We do not feel the need to mention, but no, Wizardry and Steamworks does not do that).
Perhaps some of those widely available gadgets on marketplace that show the weather around the world using media-on-a-prim, or perhaps some control panel for some service on the Internet that needs to display a webpage.
“Hey, could you help me? I am toying with my stream, I have a concert in 10 minutes, can you check to see whether you hear the stream?”
The attack vector, from a programming standpoint, as mentioned previously is trivial. The sketch below illustrates a simple clusterfuck of an avatar that rezzes an object containing a malicious script.
The following steps are performed by this attack:
The avatar is thus compromised in two steps:
Since the media-on-a-prim queries a crafted URL, such as:
only when the avatar displays the media-on-a-prim, then the PHP script on the receiving end can correlate the IP address with the GET and POST data sent by the LSL script.
Obsolete example code is available at the bottom of the page.
Third party viewers such as Firestorm tend to pitch-sell liability dumping as a guarantee for security. When they are shipped, they enable an option that allows an avatar to block or deny a connection to media streams, such as parcel music based on a popup. They literally prompt the user for some address like:
and they offer the user the option to deny or block the connection to that server.
That offers no protection at all, just an annoying pop-up since it is impossible to determine whether the destination webserver at
really-good-streams.to is well-behaved.
A webserver could easily remap the MIME settings and interpret
.pls files as PHP and the end-user facing a pop-up such as the one offered by Firestorm, has no clue whether the server is trust-worthy or not.
The only achievement is more confusion and even better masked evil servers.
Either use a VPN or tor to hide your identity from third-parties in Second Life. Note that piping your Second Life traffic over such services will hide your traffic from Linden but your viewer bypasses Linden servers so while you are hidden from Linden Labs, you are still wide-open to third-parties in Second Life. On that note, you should pass your entire traffic through those services rather than just your viewer traffic 1).
The following are sketch-level scripts that were created cca. 2010 - we noticed that it more about illicit behavior than a technological challenge, so we did not expand on them properly to get them to the level of a deliverable payload.
|client_side||LSL script to harvest avatar data.|
|server_side||PHP (or others) to receive the LSL data and the connecting IP.|