Events

« September 2008
SunMonTueWedThuFriSat
123456
78910111213
14151617181920
21222324252627
282930

User login

Get your own inworld RSS feeds - free!

Recent comments

Syndicate

Syndicate content

Second Life® is a registered trademark of Linden Lab® , as are the Eye-in-Hand logo®, Hexagon logo™, inSL Cube logo™, Linden™ dollar(s), Linden Lab Hexagon logo™, LindeX™ , Second Life Eye-in-Hand logo®, Second Life Grid™ development platform, Second Life Grid logo™, SL™, SL™ world, SL Grid™, SLurl™, Teen Second Life™, Teen Second Life Eye-in-Hand logo™,TSL™, WindLight®,Your World. Your Imagination.™

The Exchange ATM Bug Explained - Sort Of.

After Konner posted on the halt of the Exchanges, Ciaran hit the nail on the head about the silence of Linden Lab on the topic. I've been following it with interest, trying to nail down exactly how the exploit occurred, when I found it in my email - I'm withholding the person's name at this point, but I can share that the information has been disseminated to the exchanges.

Basically, how the exploit worked was through fooling the simulator into allowing someone to rez something of the same Object ID - or key. Allegedly, this exploit affects Second Life Server 1.22.4.90499, and a rolling restart will solve it once the server software is updated. It appears that this has already begun. It should be noted that this exploit required a special tool from LibSecondLife, one that was kept quiet but which someone (obviously) leaked. For the more technical folks, a modification to SLProxy made this possible.

In all, Linden Lab probably should have said something but didn't - something that is par for the course when it comes to the virtual world of Second Life. It did not just affect ATMs, it also affected other objects as well. The good news is that even with the exploit, items received through the exploit got the same permissions as the owner dictated - thus, a no copy/no mod/no transfer item would remain a no copy/no mod/no transfer item, with only the person who used the exploit getting a copy.

How this actually fits with the ATM issue of withdrawals is an interesting question, and it seems apparent that not all the information is available - and that may be for the better. The crux of it is that, at least from the White Hat side of things, this should get nipped in the bud with upgrades to the server side of things. How this could be avoided in the future is anyone's guess - some might say that the open source caused the problem, others could say that the fact the server code is locked away also caused the problem. Either way, people caused the problem - as they typically do.

And in the end, it takes people to solve those problems.

My own opinion is that the server code should be open for people to look at and make more concrete, but that is only an opinion and is as substantiated as the opposite opinion others may have.



Reply