Anti griefing proposal - Verified Scripters

The idea is to limit compilation and saving of scripts with some LSL functions, e.g. rez, give inventory, push, etc. to people who have verified identities.

Anyone can run any script, but you have to be verified to save a script with these "dangerous" commands in them. Anyone is free to create scripts without these restricted commands in them which leaves lots of stuff to play with.

If there's a problem with a person's scripts, all their scripts can be immediately disabled by just having the servers check a runtime list of banned scripters before running any code with restricted instructions. Eventually, they could be searched for and deleted and the banned scripter runtime list pruned. It would never be a long list, generally 0 entries, and only be used to kill an attack quickly.

The verification would be something like having a verified PayPal account, both an email and listed phone number that LL could test to see if you really exist, and other similar stuff. The idea is to have a high probability that a verified scripter really is a known person, could be prosecuted later if there was a problem and couldn't just create another free alt to come back once banned.

This would work by embedding the UUID of the scripter in the code when saved on the servers, so if it does malicious actions, the person who wrote it would be traceable. The servers would do the checking and embedding so it would be independent of the clients.

If you weren't on the verified list and you write a script or someone gives you a script containing restricted instructions you couldn't compile and save it.

If you write a griefing script and run it, or don't use it youself but transfer it to someone who does use it, you're on the hook.

If you don't have a VERY good explanation for a problem, you're out of SL and can't get verified again ever and maybe have some unfriendly conversations with the police. Blindly compiling someone else's script, then the running or transfering it does not constitute a "good explanation".

On the technical side of things, this won't work. The client is where LSL compilation happens, and the libsl folks have figured out how to inject their own bytecode. So you can't trust the bytecode... griefers could just inject their own bytecode.

OK, then attach the UUID when it is saved to inventory. If you aren't verified, you can't save it.

However, if it's possible to hack the byte code, then there are a whole lot of very bad things that could happen. I doubt that LL has tested all possible bytecode combinations and extensions. I used to do micocoding, and it's amazing what's hiding in the instruction bits. If true, this is a huge security hole that should be immediately plugged by hashing the bytecode, etc.

BTW, if it is compiled on the client, it would be great to have off-line compilers available.

Lex is right. This is the ugly side of SL growing pains. =(

Getting rid of all unverified accounts would have the same effect. Personally I see this as the ONLY viable way of securing SL but I know its a bit of a draconian move.





Add in the client side reverse engineeing projects and even that becomes next to useless.

Yes, it is relatively easy to do all of the following things if you are a competent software developer of practially any stripe:

1. intercept and reverse-engineer pretty much anybody's script.

2. take somebody else's script and inject your own malicious code into it, then push the hacked version back onto a server for execution. This, btw, is why some of the recent grid attacks seem to come from objects owned/created by people with no connection to the griefers at all.

How is this possible? The good folks at libsecondlife, with LindenLab's blessing and participation, have tools to intercept and modify the client-server packet stream, and they also have a fully laid out map of the LSL bytecode structure. Read it and weep:

http://www.libsecondlife.org/protocol/index.php/LSO

I personally have no clue why LindenLab supports this group when this publically available information can so clearly be used to grief and/or rip off intellectual property. I also find it quite amusing that on the group's home page, they politely ask people "not to use this information to crash the grid".

How does "getting rid" of unverified accounts fix the ability of person with verified account to use modable script originally made by someone else, change its content to malicious and release it to crash the grid with no way to pin it down on them anymore? Having people data that *may* be valid does you squat good when it cannot be paired with accountability.

Fushichou Mfume mentions some very interesting and alarming "facts" about libsecondlife in the previous post, and while it all sounds somewhat logical, it is not exactly true.

libsl is not magic, does not have some magic ability to "inject" bytecodes into a stream of opcodes that resides on the server and never gets transmitted to the client. libsl can certainly be used to create a custom client-side compiler, and also to inject bytecodes into any stream that *is* uploaded by the client. This means that you could bypass the built-in compiler and inject llPush and llRez* calls into your own code if there was not a server-side check, but it is for precisely this kind of reason that LL has been beefing up the security on the server and they are certainly smart enough to take such things into consideration.

The publicly available documentation on LSL opcode formats does not change anything. If you cannot get the bytecodes from the server (and you can't, you can't even get the source unless you have mod permissions, and the opcodes are never transferred from server to client), then you cannot inject.

I would suggest that anybody truly concerned about libsecondlife go get informed about it, rather than make guesses based on alarmist comments found on the forums. It's quite easy to get the code, the documentation is publicly available, and there are public forums for discussion.

While we all like to complain about Linden Labs, especially lately, we should all realize that the LL developers are not stupid. If they believed that there was a huge risk from libsl, or even just weren't comfortable with it, they could and would break it.

Look carefully at the quoted paragraph. Specifically your second sentence. Any time you have a way to intercept and inject custom bytecode into a client > server stream, you have the ability to perform all manner of hacking/griefing. Why do you think is is the first target of all serious game hackers, from the CounterStrike exploiters to the WoW exploiters, etc. The only way to truly protect server code is to keep *everything* relevant on the server. As long as some critical code and functions are performed or exposed on the client side, you have the potential to which I referred in my post.

Also please look at your last sentence and note your use of past perfect tense: "...for precisely this kind of reason that LL HAS BEEN beefing up the security on the server..." Which again, does not contradict what I stated. "Has been" means they are still in the process of doing so. The RISK is still there, and while LL has certainly been taking steps on their end to minimize that risk but that is why this vector of attack was successful in the past and remains a potentially successful vector of attack.

I realize that it would kill sim performance to keep all the script source, compilation, and bytecode on the server, never touching the client at all. This would be an impractical solution to the problem.

My point is only that there are always motivated hackers who have the tools to sniff the stream packets, look at the client side code, and reverse-engineer how things work. I just wish you wouldn't make it so EASY for the less-capable griefer by giving them the client-emulation tools and the bytecode maps for free.

In other words, quit defending your *public hack* site with the constant refrain that LL knows what you're doing and condones it. Sure they can't stop you or any dedicated hacker. But WTF are you giving your information and tools away free to any script-kiddie griefer who could not have figured out that info on their own but can certainly use it to grief and or steal content? If they could NOT grief/steal content, then why the hell do you even say in your very own FAQ "please do not use this info to crash the grid or steal content"?

I am not an author, and my grammar sucks, but I knew that already, thank you very much I'm not sure what purpose it serves to call that out, but it doesn't seem at all relevant to me.

I did admit that you can inject code from client to server, and that without server-side checks that can be a problem, but that does not confer some magical ability to steal and modify someone else's scripts as you said in your post.

Any time you have the ability to modify someone else's scripts, you can do so without the use of libsl, you simply use the built-in client-side compiler to do that. There are any number of exploits that allow "bad things" to happen in SL that do not require and are not even enhanced by libsl.

I already knew that libsl can be used for malicious purposes. I never intended to suggest otherwise. The primary purpose of my response was to point out that your so-called facts were not quite correct in all cases and that you were making alarmist statements without having direct knowledge of how libsl works and what is and is not enabled by it's use.

I do not suggest anybody write off libsl as a security problem, but I do suggest that they become informed about it.

Responding to the repeated use of the word 'you' in the previous post:

I am not a libsl developer, am not associated with libsl in any way, and am not responsible in any way for libsl being publicly available.

I am just one of the people who went and downloaded it and poked through the code out of curiosity, and implemented a chat and IM logger so that I could keep a history of all of my SL conversations.

I also frequent the libsl forums and subscribe to the developer newsletter, and know that the real libsl developers have the best of intentions. They are actively working on extending and enhancing SL with offline builders, mobile clients, and any number of things that are harmless and possibly quite useful.

Clearly you are not well informed about libsl and have no idea what you are talking about with regards to it's capabilities or the intentions of the actual developers.

And calling me a hacker is completely without merit. I don't understand why you feel you need to resort to name-calling simply because I pointed out that you were alarmed but not completely correct about the extent of libsl's support for stealing someone else's code.

Before this thread devolves into a flame war, I'd like to suggest that even if it were possible to upload script bytecodes, change them without running the compiler, then put them back onto the server that has no impact on my original suggestion.

Unless there is a way to spoof the login process, the server knows who is doing the uploading. The code would simply be scanned for restricted instructions, and if present the user would be checked for being a verified scripter. If so, his id would be embedded in the script metadata, if not, it wouldn't save and would emit an error.

This seems a pretty trival change to me.

Quite right. I apologize for my misguided attempt to sidetrack your thread, and will leave immediately.

And for the record, I largely support your original suggestion.

Takuan - thanks for your comments, I'm not trying to toss anyone out of any thread, I'd just like to keep it meaningful and on point.

It will be a sad day when (and not, "if," apparently) LL does this. I and several other very competent programmers are interested in SL primarily for the ability to script in it. We contribute great things to the SL community and economy. Restrict the ability of new people to script and you will be turning away quite a bit of new interest and probably losing a fair number of fabulous and creative people who are already here.

LL has apparently chosen to do this, and the only reason I can think of is that they are not creative and competent enough to: 1.) create a good set of tools to deal with attacks with minimal manual intervention and no down-time, and 2.) shore up the holes in their design to generally prevent such attacks in the future. It is terrible to think that LL doesn't have the confidence in their own abilities to implement the RIGHT solution. The answer instead is to ask residents to give up their creative ability and/or anonymity.

If you run an internet cafe and find that people are being able to exploit your systems somehow, what is the answer? Do you: A.) fix your systems, or B.) shut down shop because you can't have just ANYONE using your computers?

oo, any chance you can make that publicly available? I would love to log my chat and IMs.

That could work, sure, but only if it's done on the server.



I don't know that the risk is as bad as you think. Malicious bytecode might make the bytecode virtual machine do nasty things, but there's probably no more risk of that than there is of malicious data streams making the sim do bad things. I imagine they've taken that into account and coded defensively to protect against it.

Anyway, with the technical details aside, I've got to disagree with your original idea of limiting things like llRezObject and llGiveInventory to verified accounts. When I joined SL, I took the whole money/economy situation as kind of a challenge. Back then you had to pay $10 just to sign up, but if I didn't have to pay, I wouldn't have given my credit card information. I wanted to see if I could create and sell enough content that I could earn the money in SL to pay for my own account. I did exactly that, releasing a few nifty products as a basic account, and cashing out my first $20kL to pay for my account for a year.

In short, it was possible for me to come in with next to nothing, and scrape out a second life for myself by employing my skills. And if the deck was stacked against me so that I was limited as to the scripting functions I could use simply because a tiny percentage of new users try to take the grid down, I'd be pretty frustrated! Go look at some of the free things I've released in the scripting library forum. They'd be gone if I'd left in frustration. We've got to be careful so that we don't drive off someone who could be one of the next greats of our community.

This proposal is specifically designed not to have that effect.

There would be nothing preventing a person, even on a free account, on day 0 from getting verified scripter status. I suspect the griefers have been around a long time, since it takes at least a little experience with LSL to write a gray goo script. Their alts are noobs but that's not relevant.

This proposal does require that if you want to use dangerous instructions you can't do so anonymously, you have to let LL have a reasonably reliable ID for you.

Also it's not like every interesting script has to rez something. There's lots of fun and very challenging things to do with LSL that can be done with safe instructions. This proposal has no restrictions on them.

My comment about your grammar was to highlight that you yourself were not saying that LL had *already* fixed the security holes posed by libsl. Instead, you were saying that LL is constantly in the process of trying to deal with the possible vectors of griefing due to injected bytecode and other exploits that can be accomplished through client > server stream manipulation. I wasn't picking on your command of the English language; it's quite fine.

As for "calling you a hacker", that is not an intended insult. It is a statement of capability. The mere fact that you have used tools outside those provided by LindenLab to intercept the client-server datastream to create your own logging utility is indeed HACKING. Therefore, you *are* a hacker. Whether you feel the term is insulting isn't an issue for me. Sheesh.

As for my interpretation of the potential risks of the information and tools on libsl, I stand by them. I've personally hacked enough games in my lifetime to be aware of how things are done and what the potentials are. So many in fact, that I cannot even name them all. Including at least one MMOG (Asheron's Call 1), which is why I have some idea of the issues involved here.

Yes, it's quite possible that the source code of a script is well-enough protected unless you can manage to intercept the datastream of another person's client and log their packet data. (Which is difficult but not impossible.) I haven't dug far enough into the libsl capabilities and tools to every find out for certain, because I have personal ethics against griefing. But why is it inconceivable that when you reset scripts in an object (and you do not have to own it to do so) some type of bytecode recompiliation and traffic isn't occurring between the client and the server? Again, I don't *know* for sure and would welcome a full explanation of the process from someone who fully understands what's going on under the covers. But my point is that based on past experience of how other similar systems work, it's not *inconceiveable* that there is an exposure in that regard.

Again, I point you to the fact that on the site's FAQ, they prominently request that people do not use the information and tools on the site to A) crash the grid, and B) to steal content. Why, I ask, would they need to put this polite disclaimer on the site if it were in fact impossible to accomplish either A or B with their tools?

I've presented my objective opinion here. I may be wrong on some points. It's up to readers of this thread to decide for themselves (or to present more informed comment).

Because unverified accounts make it very easy for a greifer and hacker to make a false account, to get into sl easily from any location, and with no way to verify who this person is, They have very little fear of being caught so they continue to cause the rest of us greif.

Well, the original proposal is designed to "limit compilation and saving of scripts with some LSL functions, e.g. rez, give inventory, push, etc. to people who have verified identities"

Since currently the only supported way to "verify identity" is through providing one's CC data... and Hewee's point was, there's a lot of people who are unable or unwilling to perform this step, and as such would become locked out of this access... thus, a natural follow up to this new comment how it would not be the case... is i guess, "then how does a person get verified scripter status?"

Please read what i said, as your response has nothing to do with it. My point was, you can remove all unverifieds accounts whatsoever all you like and it does nothing to make the *verified account holders* accountable for their actions. The same griefers can do all their happy work with the verified accounts and you won't be any better off, because they have very little fear of getting caught, *either*.

BTW for those interested, please take a look at Kelly Linden's comments in this thread over on the Linden Anwers forum. I find what she does not say every bit as interesting as what she does say.

/invalid_link.html

Would you like crazy alarmist rhetoric with that? Just because libsecondlife CAN be used for ill doesn't mean it shouldn't exist. Also, I didn't weep when I read the LSO file spec. I'm fairly sure that's NOT the holy grail the griefers are after. They really want that BOX the holy grail came in, that when opened, griefed the whole room of Nazis.