Copybot - does it rely on a protocol flaw?

I don't know if this has been brought up before (the signal to noise ratio on copybot discussion is kind of high right now), and I haven't got hold of a copy of the copybot source code to get a grip on what it's doing for myself, so might have the wrong end of the stick... but, this is a message I just posted to Linden Answers. I thought I'd put it here too, for non-linden input.

* * * *

Here's something confusing me about the copybot:

It can copy prims. That's a given. I understand that it does this by intercepting the prim paramaters that arrive at the client, and sending back "build" messages to the server with exactly the same parameters. It's a bit like a human user rezzing a bunch of new prims... (albeit with ruthlessly fast accuracy and efficiency) - and I can see why it's not really feasible to put server-end guards against that kind of client behaviour.

Here's the bit that I don't get...

Having rezzed all these prims, the copybot then manages to attach texture asset IDs to the new items... texture IDs that a human operator, at the same client, wouldn't have reproduction privilidges on.

Intinctively, this strikes me as a flaw. An exploit. A security fault at the server end of things. The server should _not_ be accepting requests from a client to associate a "prohibited" texture to a client-rezzed prim.

Do your servers blindly accept messages from a client to apply *any* texture to a prim? Did you assume the client wouldn't fall into enemy hands? ...and would always be well-behaved and only request textures that the user was entitled to request?

(OK, dumb question. We know this the kind of oversight that brought about the existance of megaprims)

If the security model was - hypothetically - less trusting, then the copybot would only be able to rez "plywood" copies of stuff. Yes, it's possible for copybot users to extract textures via other means, and to upload + apply them manually - but at least that would cost them L$, time and effort to do. It stops the copybot being a casual "drive-by" cloning device; that's what a lot of people fear.

Anyway, here's my questions:

1. Is the copybot using a security loophole to reproduce the textures when cloning items?

and if so:

2. Any chance you could... urm... close this loophole anytime soon? I'm sure many content creators would be a _little_ happier if the copybot was restricted to generating crappy plywood clones of their wares.

If (2) is viable... could you publish an ETA? Then content creators could make a sensible risk assessment / business decision about taking their prim wares off the market for a while, and putting them back out when your servers are fixed.

IMHO, this would be a *massive* step forward by LL in mitigating the hysteria surrounding this loophole, and restore a lot of faith from the content-creating community.

Shep K.

it's possible that copybot is also relying on intercepting OpenGL data at the same time, and is then reinterpreting the data.. and reuploading the textures. Of course, that would cost MONEY (and not a little).

This is something I am very interested in.. in terms of user A being able to access user B's textures by UUID numbers alone?

This does indeed sound like one thing that LL should be investigating, and fixing if it really is happening. If they're capturing and processing the textures and reuploading them to the grid.. that's not something that can practically be stopped. though some have suggested that it might be obfuscated with some encryption? That would be good, if it can be done.

I suspect though, that the copybot it something of a "super user" because it can detect data on the client/stream level.. much of which the average user does not have access to. (which explains some of the controversy). It's possible that it can make use of some of that data in an inappropriate way...

This may be some of the "security measures that have yet to be completed" that LL was speaking of in the recent blog post. underlying insecurity of the data stream, that libSL has uncovered.. and LL was caught "by surprise" figuring they had some time to solve that issue.

I've just been assured by somebody via PM that this _can_ be done... and by the humble llSetTexture command too! (I always thought you could only llSetTexture via UUID if the target texture is fully permissive).

If it's true that you can use *any* UUID with llSetTexture.... then.... wow.... I'm speechless!

It is true, but keep in mind that normally only the person having a copy of the texture in their inventory has the ability to derive that UUID.

CopyBot gets around it by reading the UUID's from the incoming datastream directly, and sending those same UUID's back out to describe its own appearance or the appearance of prims it's duplicating.

Also, keep in mind that textures, in order to be usable at all, have to have their modify permissions turned on. Copy protection of textures has always been extremely thin to start with.

Thats exactly how most vendors work.

Oh. Forget this stupid "saving the world from copybot" nonsense then. Soon as I get home, I'm going to start fishing random UUIDs for embarassing porn...

(seriously. Security by obscurity in THIS day and age? I'm stunned!)

That's not true.

Hasn't anyone ever hit ctrl-alt-shift-t with "view admin options" turned on?

Getting the texture UUID of any texture has been available in the client for ages.

I reported it months ago and LL said it wasn't an exploit.

I knew about the possibility to refer to UUIDs with llSetTexture, but I always trusted that the owner of a full permission texture would be the only one who can grab that UUID. I'm speechless that it's that easy.

Oh! Of course, you're right. D'oh.

Finally someone I can talk to about this; I've talking about this for over a year and everyone I talk to, their eyes just glaze over.

1. Is the copybot using a security loophole to reproduce the textures when cloning items?
Yes and No. We will call this the Use-Build UUID Loophole (UBUL).

2. Any chance you could... urm... close this loophole anytime soon? I'm sure many content creators would be a _little_ happier if the copybot was restricted to generating crappy plywood clones of their wares.
UBUL would be a pain to close and would only protect new assets and not old assets (animations, sounds, textures); not to mention the user could just re-upload (this could be easily automated).

UBUL is not a new problem. Here is an example:
I discovered an exploitable UBUL in 1.4-Preview when user animations were introduced, the llPlayAnimation at the time allowed the user to play animations by UUID. In 1.4 they introduced a function llGetAnimationList that listed UUID's playing on the requested avatar. So I setup a bot to scan avatars for animations UUID's (a lot of sex animations are hilarious taken out of context). Then I could play them on my avatar. LL fixed it by axing UUID support from llPlayAnimation.

The problem is that UUIDs used when building are Identical to the UUIDs that are used to access the asset. Meaning that if you can glean UUID's from the client rendering (there are many ways) you can reuse them. When I first told LL about this they were like "So what, they could just re-upload." This took me aback and I started to rethink things.

You either...
1) Allow people to glean UUIDs. If they use it then that use is a record of the theft.
2) Protect UUIDs and force people to re-upload; creating no definite records beyond who uploaded it.

One solution allows you know there has been a theft (by grepping the asset server). The other solution allows you to identify who the thief was if you identify an object using a stolen texture. With the first you also have object creation records that *may* give you the thief's name.

It just so happens that the solution LL uses is the first solution. Changing to the second solution while possible would require redesigning the asset system and wouldn't protect old assets anyway.

Just to detail how the second system would work...
You would have a wrapper UUID for building. Through Inventory you could request the build UUID (this would replace the existing UUID option). This UUID could be used in script etc. All functions that use this UUID would translate it at the server side into the asset UUID; that asset information would be transfered back as applicable. There would be no way to translate asset UUIDs into build UUIDs; requiring re-uploading of the asset to get a build UUID (one way street).

I can't say which system is better but I can say current system is simpler.

-------

I mostly use UUID's for reading notecards & placing textures on prims (can use them for sounds too though i don't use sounds often). Using UUID's in LSL is really really useful and stripping this feature from LSL would break alot of content.

For example I built a tail that when the position of the tail is to be changed, it sends a bulk linkmessage to all the prims with the uuid of the notecard which contains the attributes for all the prims in the tail (21 prims presently). Each prim has a dedicated line in the notecard for it's settings. Since they all read the notecard at the same time the prims all move at about the same time. I've made 15 states for the tail using this system.
Because of how I've scripted it, adding a new state only requires build it, dumping the state to chat and putting it in a notecard (then putting the notecard in the tail); or about 15 min.
Removing UUID support would require me to change how the tail functions, to not use UUIDs would require more CPU time (aka Lag)

There's a bigger problem though.

In order for you to display an object you need your client to have full details of every visible property (which is just about everything except scripts and object contents)

The LibSL project is hard at work providing a full set of tools that can take this informarmation and then use it to recreate the object using 100% original prims and re-uploaded textures. (I know that's not what CopyBot does now, but if LibSL carries on soon it will)

There is no way to avoid this inherant vulnerability, but sponsoring a group of hackers to reverse engineer the SL protocol and publicly release what they find is just stupid. I know the lock on my house's front door can be picked, but I'd still get rather upset if automatic lockpicks were freely available. I was willing to work with the theorectical risk of client-side content theft, but I'm no willing to work with widely available client-side content theft supported by Linden Labs.

It's easier to keep control of hackers when you sponsor then instead of vilify them. They have found a large number of critical bugs. What if they had used them to crash the grid instead? Hackers screw up, it's human. Nobody has perfect judgment. Keep your friends close, your enemies closer.

I too wish they hadn't published their works. But there is little I can do about that.

Since assets like textures are not copied in inventory, but rather the inventory just contains a reference to the UUID, there's another option:

3) Allow people to glean UUIDs, but don't allow them to use those UUIDs unless:
* Their inventory contains a reference to that UUID, or
* The contents of the object contains a reference to the UUID, or
* They have appropriate permissions on that UUID, or
* The *creator* of the script that's using the UUID has appropriate permissions on the UUID, AND
* in the last case, the bytecode of that script was uploaded by that creator or someone with "god mode" rights on the server.

Everything in inventory is done by UUID. Permissions are not actualy associated with the asset directly. But your suggestion works great none the less with everything else that uses keys, so no changes need to be made.

Except for the huge number of extra database queries and the cries of lag.

They can't pretend it was done for security when they knew libSL were releasing all their work publicly, and that LibSl's intention was and still is (supposedly) to make a full open source client.

That alone show the stupidity of LL in allowing this... an open source client will kill all pretense of permisisons meaning anything, and without the tier fees and Lindex fes from IP sellers SL will rapidly die. They may survive this, since sellers will slowly creep back in, but they've shattered the confidence of everyone who didn't know just how vulnerable SL always was.

That confidence should have never been there in the first place. Sellers of prim/texture items should have known right from the start that there is no real way to protect those items. It's better late than never that they find that out.

LibSL only got the word out, don't kill the messenger.

lol, they did more than "get the word out"

Agreed.

Telling a homeowner the lock on his front door can be picked is fine.

Giving away skeleton keys that open every house in the city is not.

it's called a bump key.

the fact bump key exist mean nbobody should be able to open a locksmith business? As far as i am concerned you don't need any autorisation to start cutting keys yourself.

LL should have told us up front then. Why do we need Libsl to tell us what LL has known all along?

And I think that right there is the true source of the anger and the frustrations thta many are feeling right now. LL knew that these issues existed, and instead of LL telling them, a group of hackers told you, and told you how it was done, and even gave you a copy of the script so that you could do it yourself, in moderation of course.

As a network security specialist, I can tell you guys that hackers are NOT the enemy. This in general is indeed how they work. They take a program, and scrub and scour it for any and all flaws that they can find. They use predesigned scripts and programs, they write new ones, they do anything and everything they can to test the vulnerabilities of said program. They then alert the program creators to their findings and one of two things happen. One, the creators say "oh shit! We gotta fix that!" and get right on it soon releasing a security patch, or they say "eh, it won't really be that much of an issue" and ignore it. (This is risk vs. cost assessment. Which costs more? The cost to get rid of the risk, or the cost to the company if the risk is exploited. Sometimes, companies choose wrong.)

Now the hackers have told the creators that their program has some serious flaws in it that needs to be fixed for the safety and security of the other users. Company says "meh. No one else knows, and these guys will keep their mouths shut if we ask them nicely so we can keep our heads buried in the sand." But the hackers know that if they found this flaw, then someone else probably has as well, and is probably exploiting it for their own purposes while keeping their mouths shut. (These guys are known as "Crackers." This leaves them with a bit of a moral dilema of their own.

Do they keep their mouths shut, and everyone who has their head in the sand can keep it there, or do they anger an entire community of people by telling of the flaw, and telling how to use it? The first one puts the community in more danger so to speak, but the second one puts their own heads in front of the firing squad.

They did as any ethical hacker would do. They told the community, loud and clear. They even showed you the tool that can be used to do it and told you how to use the tool. Why? Because education is the BEST possible defense. Knowledge is the best prevention. It isn't enough for me to tell the typical user that "hey, I can exploit a Microsoft vulnerability on your computer using this little program, and turn your webcam and microphone on and listen and watch every little thing you say or do" because the typical user will NOT believe me unless I show them and show them how it is done. (And yes, this is a very real situation. Good reason to unplug those mics and cams when not in use.) Instead, I must show them that I can do it, and show them the tool that I use to do it, and then they understand. (In reality, I'd set up a test server to show the other users on and for them to test the program on themselves just so that I don't go to jail myself. lol)

In essence, this is what LSL has done guys. They pointed out the flaw and they let you guys know about the flaw and in an attempt to educate you, they released what I suspect is a scaled down version of the program so that you can see just what this does.

Hackers do this for two reasons. One to educate the public domain about it (us being the public domain) and to also garner support in their efforts to have this flaw changed. It's easy to blam LSL for this flaw but it isn't their fault that it exists. And I guarantee that if THEY found it, someone else did as well. I also guarantee that the others that found this flaw did not create a scaled down version of copybot for demonstration purposes. No, they created a full version of it so that they could copy the full prims, etc, and KEEP them. Not lose them when their client shuts down.

They could easily have kept their mouths shut. They could easily have not attempted to educate the community on this issue and allow it to continue. But they didn't. They chose the difficult road. The one that they knew would place them in front of the firing squad.

Now that we know these vulnerabilities exist, what are we going to do about it? Or are we going to keep focusing on the messenger?

Actually, that is a common falsehood. Open source programs are often more secure than closed source programs because there are more people scrutinizing the program, looking for it's vulnerabilities, and working to secure the program than before. Take Linux for example which is based off of Unix. Linux has been in the past, primarily open source, and it is one of the safest operating systems there is. Even their more user friendly versions are more secure than the closed source operating systems out there. I'd switch to Linux for all of my everyday usages, except many programs that I use are not Linux friendly.

Open source programming has proven in the past to be more secure, and safer, than regular programming. I believe that an open source platform would be more secure in the end than the current platform is,and probably less laggy as well. Open source would also allow the more knowledgable users to code their own security into the program as well.

Why are they enemies at all? They could easily have kept their mouths shut, or even used the flaws for themselves. *shrugs*

I am glad they released their works. The key to security isn't in what kind of locks that you have in place, the key is actually in knowing how those locks can be picked so that you can design better locks.

It is common in the networking world for a large company to set up a test network that clones their current security system and then to hold a contest, or invite the public to come and try to break into their network. Why? They want to know what their vulnerabilities are.

Yep, they should have done what Steve Jobs did. He told the record companies up front that DRM wasn't workable, and he still talked them into putting their trust in the iTunes store.