Scripters Beware

An interesting read - The L$100,000 Scripting Lesson:

http://www.secondlifeherald.com/slh/2007/06/the_l100000_scr.html#more

While the 'bad guy shouldn't have exploited it, the guy was pretty dumb not to secure his machines, or at least make sure no one could find out how to use it against him

aye as tiny as money functions are there should be no real reason to have the 2 on different scripts which would have avoided the whole incident

but its also a lesson to newer scripters, its not that hard to link a prim and intercept internal linked messages, so keep it in mind when dealing with anything real

<resmod>It's against forum policy to discuss the persons in question. Discussing the technicals of the scripting would be appropriate.</resmod>

Here is probably how the System was designed.

*HUD*
Main HUD Script
Email Relay Scripts (to get around the 20 second llEmail delay)

*Server*
Server Scripts

This looks like a classic script injection attack.
The HUD was either mod or the scripts were pulled from the HUD to analyze them. So the attacker added a script to intercept the link_messages between the Main HUD Script and the Email Relays. Once the attacker had determined how to make a fake message they sent one to exploit the server remotely.

There are a couple ways to protect against this type of attack. Using all of these may be overkill but using only one will provide a considerable road block to any attacker.
1) Validate the inventory and/or the containing object.
2) Encrypt the communications.
3) Sign the communications with a hash.

When choosing a signing or encryption algorithm, do not rely upon one that uses only an integer as it's seed. An integer seed can be brute forced in less then 24 hours on most desktop computers built in the last 5 years (algorithm permitting of course).

But... still confused. For the swindle to have worked, seems the Server object (to which unencrypted messages were sent) must have had debit perm from its owner... which means that, for some reason, it was paying out L$s. I must be missing something, but why would a gaming device's *Server* ever pay out L$s?

Does anyone know whether a usable public key encryption module has been written in LSL?

I'm NOT talking about standard key encryption (like the XTEA), but rather an RSA-like public key encryption?

It wouldn't need to be a crazy high number of bits -- just high enough to deter brute force, not to deter governmental agencies.

It would pay out when someone won.

Yes RSA has been translated into LSL, it's slow.
https://lists.secondlife.com/pipermail/secondlifescripters/2006-October/000158.html

Oh, that explains it: No wonder my gambling scripts were so profitable! *wink*

In fact, though, this is backwards of how I thought gambling devices worked. Rather, I always thought the devices only siphoned off a little of each bet to the syndicate's servers and handled wins local to the device. But come to think of it, that would require the device owner to have sufficient L$ balance to pay out those occasional pesky wins.

These gambling devices were HUDs. So the object owner was also the person playing the game. So when you won money, the object had to tell a server to pay you.

I'm guessing when you attached the HUD, it requested permission debit from you so that it could pay the "Casino Owner"

Oh, indeed: So they were. I'd repressed the idea of *wearing* a gambling device. /*Qie squicks.*/

What I don't get is how the "slot hacker" managed to extract the scripts if the object was no-mod...

You CAN remove things from no-mod objects, though you get a big warning about doing it. You just can't put things IN.

I've tried with a couple objects, and it actually works. I'm really surprised, cause it looks to me like a dumb feature behavior. What use is the "no-mod" check if people can take out stuff from your objects, and as we've seen in this slot-machine cracking, expose scripts to attacker analisys?
As I see it, if an object is marked no-mod, you cannot modify ANY aspect or property whatsoever of said object.

Though a bottom up approach would be useful in some cases. Like an item with a config notecard. notecard is full perms, but unless the object is mod it still can't be edited. That's really annoying and a major issue when things like sculptie maps need protecting. There's also gift / packing boxes where you don't want the box moddable but do want people to be able to pull things out. It's a tough one to get 100% right.

As far as protecting scripts, something like

if ( llGetCreator() != "expected uuid" ) llDie();

along with other verification techniques can help. Above on it's own is of limited use if you have released moddable objects as they could use one of your own prims as the basis of the cracking.

It's actually pretty important to be able to remove things from no-mod stuff, now that there's a lot of it out there built with the expectation that contents be removable. (Poseballs are the biggest one for me. I'd never buy any animations at all if I had to leave them in dorkey poseballs.)

What you say is right Qie, but on the other hand, as we've seen, such behavior poses a security risk. Maybe only objects with mod enabled should be made extractable? OR some permissions combination like that..?

Now that you mention it, it seems like the Object permissions currently confound both the permissions on the prims involved (size, color, etc.) and *partially* the manipulation of contents (can't add stuff, but can remove). Personally, I hardly ever buy anything that I leave intact, so that ability to remove stuff is real important to me, but in fact the permission to put more stuff into a pretty prim really shouldn't have to be entangled with the permission to make it prettier.

But I sure wouldn't want the task of revamping the permissions system while trying to maintain any coherent backward compatibility.