Gemini CDS Ban Relay: Conclusions

Continuing from where I left off in my previous post on the subject, I am coming back, this time with the opinion of an internet security expert. You see, in RL I happen to work for a software company and this obviously gives me acquaintances with people who are in the IT business. Therefore, it is only natural that they can offer me some concise, accurate information on many issues where my knowledge isn’t enough. Deciding not to be “The Scotty Who Knew Too Much“, I handed all the information I gathered during my investigation of the whole Gemini CDS Ban Relay to a friend who is an internet security expert and a participant in the local chapter of the OWASP (Open Web Application Security Project). So, I asked him for his educated opinion. Here’s what he has to say on the matter:

“The Gemini CDS Ban Relay basically relies on requests that are sent and received, for example through Wireshark. These are in HTTP protocol, so the Gemini CDS may indeed compile the whole thing in Ruby as it claims and identify the copybotters.

But, if users use HTTPS, then the Gemini CDS Ban Relay cannot do anything about them, so it is effectively bypassed.

There are comments from people who use it and claim it works well. The thing is, after the data is collected, does it remain confidential? Is it used properly, i.e. as a tool to ban real copybotters? Is it used exclusively and safeguarding users’ privacy to track and ban real copybotters? Or is it also used to track and target each individual user through Gemini CDS Ban Relay, even arbitrarily and vindictively, just because they said something against this system and/or its creators or users? This does raise a serious issue of legitimate data use, even if the data isn’t “private”. Then comes an issue mentioned in the post you gave me with the technical analysis of what the Gemini CDS Ban Relay does. It says:

‘The second field (title) turns out to be my avatar name, followed by the sim name (licensedon), a UNIX time value (tvowner), and what looks
like an MD5 hash (videoid). The time value is apparently used to prevent replay attacks: it is possible to immediately replay the request exactly and get a success response, but after about 30 seconds it causes an internal server error instead.

Visiting the parcel again to get another URL shows that only the time  and MD5 hash change. Tampering with the values causes an immediate
error redirect, which suggests that the MD5 hash is a signature to prevent forged messages. So, even though we could encrypt arbitrary
values and send them, we’d need to know how the signature is generated for them to work.’

The response from the server is innocent enough:

<html><head></head><body bgcolor="#7f7f7f" leftmargin="0" topmargin="0">
<img src="video-background.gif" width="2000px" height="2000px" border="0px" />

The video-background.gif file is just a transparent 1×1 GIF image:

00000000  47 49 46 38 39 61 01 00  01 00 80 00 00 7f 7f 7f  |GIF89a..........|
00000010  00 00 00 21 f9 04 00 00  00 00 00 2c 00 00 00 00  |...!.......,....|
00000020  01 00 01 00 00 02 02 44  01 00 3b                 |.......D..;|

These are the only requests that are performed. Nothing nefarious appears to be taking place. There is no evidence of any kind of exploit, or the transmission of any kind of private information. So how does the service detect “illegitimate” clients?

The magic turns out to be in the “User-Agent” request header, which identifies the client. In my case: Mozilla/5.0 (Windows; U; Windows NT 6.0; chrome://navigator/locale/; rv: Gecko/20090305 SecondLife/Emerald Viewer (default skin)

By using curl to replay an old request, and simply replacing “Emerald Viewer” with the name of a random client from the Onyx project (NeilLife), I was able to get the system to ban an alternate account I created. Note that this worked even though the time value was old, and the HTTP response status was a 500 error, so it would appear that the system to prevent replay attacks is broken. Looks like they’re up to at least 1 false positive, even if it’s a technicality. Also note that the actual response body did not change, so there doesn’t seem to be any kind of exploit that is only sent to users of “bad” clients.

Using the same IP address and computer, I was able to go back to the same parcel on my main account with no trouble.

So, in the case in question, the Gemini CDS Ban Relay either makes effective use of the MD5 hash or, as mentioned in another post, the account receives an IP-based ban – and we all know how ineffective these are, because, in the latter case, it is only a matter of changing one’s IP through a router reset or use of a proxy server to bypass the Gemini CDS and cause it to fail. Ask any forum administrator or moderator and they’ll tell you. And, as was displayed in the paragraphs I quote above, even this IP-based ban didn’t work.”

What does this all mean? To me, it means the following:

  1. The Gemini CDS Ban Relay may indeed work under certain circumstances.
  2. The Gemini CDS Ban Relay is NOT the “silver bullet” it is made out to be by its creator(s) and users.
  3. Its use and function raises serious privacy issues and it needs to be investigated if and to what extent the use of the data collected is in accordance with Linden Lab’s ToS.
  4. It does cause false positives (against its creators’ claims).
  5. It can be bypassed.

So, is it worth the L$ that Skills Hak asks for? In my view, no. Not at all. Not in the slightest. Furthermore, Skills Hak’s past history in Second Life (his involvement in the Emerald Viewer spyware & DDoS attack controversy, as well as his connection to people who were copybotters themselves) does not make him a credible “defender of content creators’ intellectual property” and certainly does not make him reliable when it comes to handling people’s data (private or not).

Of course, much of this is a matter of attitude: if a content creator/merchant/club owner is paranoid and thinks everyone who visits his place of business is there to “steal his intellectual property” (i.e. treats all his potential customers as potential thieves), then don’t expect him to stop being an asshat (because that’s what he is). And just how responsible is it to entrust the protection of your intellectual property and the handling of your visitors’ and potential customers’ data to a person who, judging from his past, should have been permanently banned and blacklisted from Second Life?

In my previous post, I said it all boils down to asking yourselves: Who do you trust?

Do you, the SL consumer, trust a content creator that believes – no, is convinced that you are there not to buy his/her virtual goods, but to steal his intellectual work and deploys systems that violate your privacy?

Do you, the SL content creator, trust persons who were involved in one of the most awkward controversies for Linden Lab (the Emerald Viewer spyware and DdoS controversy) and were part of a team of copybotters with the protection of your intellectual property?

Do you, the SL consumer, trust a company that fails to enforce a zero-tolerance policy against spyware, scamware or malware in its virtual world?

These are the three hard, painful questions that the SL community must ask itself, reflect upon, and answer.

The way I see it, Linden Lab ought to finally enforce this zero-tolerance policy against spyware in its virtual world and make a stand against peddlers of “snake oil” and “silver bullets”. Until then, caveat emptor. Content creators must become more responsible (and less paranoid) and consumers must learn to reward with their L$ only those merchants and content creators that treat them with respect.


Mona (formerly slutrix)




First posted at: