How Secure Is Second Life – Really?
by Alphaville Herald on 25/10/09 at 1:21 pm
Reformed über-griefers Plastic Duck and DeadlyCodec disagree on security analysis
by Pixeleen Mistral, National Affairs desk
It was pure coincidence, but shortly after Linden Lab released a compulsory client update to address "a potential security issue" last week I ran into Timeless Prototype and Huns Valen at Philip Linden’s swank new house in P Squared sim. We lounged poolside and speculation turned to what sort of problem the Lab might be addressing – the Lab’s terse announcement was less than enlightening. Could this have anything to do with the SL security advisory DeadlyCodec had been quietly trying to get the Lindens to respond to since early September?
As we chatted, it was clear that neither Timeless Prototype nor Huns Valen feel the Lab is doing much to encourage resident security exploit reports. Do the Lindens realize their L$ spacebux reward (L$10,000 – about $37 USD) for security problem reports is considered a bad joke? Or is this by design? If the Lab's goal is minimizing costs, de-motivating the security community with small game currency rewards might limit Linden staff time spent on security issues – ignorance is bliss, at least at first.
In any case, respected scripters such as Timeless Protoype are not planning an exhaustive analysis of SL for L$10,000 spacebux per exploit. As Mr. Prototype said, “It's not worth my while to spend my time researching the code security in the SL client. Security flaws are only found where security researchers are looking”. So why was DeadlyCodec trying to get the Lab’s attention? Itcouldn’t have been for the reward because the Lindens have apermaban-on-sight policy for Codec – he would never be able to spendthe L$s.
DeadlyCodec – Joshua McCracken in real life – used to spent his time developing in-game weapons for the Patriotic Nigras – a notorious Second Life griefer group, until he eventually lost interest in Second Life. I'd occasionally run into Codec over at Raph Koster's Metaplace beta, where Codec said he had helped Raph's people identify some security issues, but I hadn’t heard from Codec for months.That changed in early September when he dropped off a security analysis claiming Second Life has serious issues with code overflows which might allow for hijacking a client computer – although this had not been conclusively proven.
When he sent the security report, McCracken told me has been working as an independent security consultant, which could explain his motivations. If security consulting is a reputation-based game, gaining and maintaining street cred is vital, and a well-publicized exploit report would certainly not hurt business. But life is never simple. Security researchers tread a fine line when publishing detailed reports of potential security exploits.
Herald reporter's chat with Timeless Prototype moves outside SL to avoid the Lab's big ear on private IM – Huns Valen spins in place
While we were chilling out at Philip Linden’s pool, Timeless Prototype pointed out the balance between the public’s right to know and the financial interests of the affected companies is far from settled. Embarrassed companies have been known to sue for damages after disclosure of security issues, and this potential legal threat has a chilling effect on the security community’s dialog. Yet without a credible threat of disclosure, the motivation for fixing security issues may be lacking. With Mr. Prototype’s advice in mind, I send the Linden security people an e-mail asking for permission to publish McCracken’s detailed analysis over a week ago. I’m still waiting for a response. It is likely to be a very long wait.
Joshua McCracken was less circumspect, and published his detailed analysis on his blog last Sunday. McCraacken’s revelations brought a swift, sharp response on his Facebook page from none other than Plastic Duck’s real life typist Patrick Sapinski, another reformed SL troublemaker.
Honoring the traditions of all classic board wars, Plastic Duck vigorously rejected DeadlyCodec’s analysis, saying, “No Joshua, being able to crash your own viewer because you fed it a bogus integer doesn't signal the presence of unsafe programming practices AT ALL. We find overflow bugs in SL every week: http://tinyurl.com/ykvdtqx. The severe ones allow you to crash other viewers at their worst, and nothing has ever been found that could possibly indicate the presence of a remote code execution exploit.”
Sapinski’s Facebook swipe at McCracken led to a relatilation post on McCracken's blog that could have developed into an all out board war, but Sapinki seemed to lose interest – or recalled that feeding the trolls is not wise – and what passes for peace in the blog-o-sphere was restored.
Whatever the merits of McCracken’s specific analysis, his basic thesis – MMO game software could present a potential infection vector for players' computers – should raise questions about how seriously the game gods are taking their product’s security and where security discussions will take place. For now, the dialog about potential systemic flaws in Second Life is being intermittently played out on Facebook and personal blogs without visible Linden involvement. Is this wise?
furfag4ever
Oct 25th, 2009
The concept of a reformed griefer always makes me laugh. Following the PN and other chantard and goon credo of once a furfag always a furfag, i say once a grieferfag always a grieferfag. I believe in forgive and forget but i make exceptions for these kids.
A guy
Oct 25th, 2009
Patrick Sapinski was just attempting to sound more intelligent than he is. Vulnerabilities are reported all the time without POC code, some of them are even CVE’s – which means that advisories are released that impact widely used software without POC and sometimes even without determining whether or not the vulnerability is exploitable. Seriously, some of them just result in crashed daemons or clients. The libpng exploit was one of them. Many advisories still state that exploitability is undetermined.
Sapinski just doesn’t have any real understanding of how memory corruption bugs work. He also has no real knowledge of how disclosure works in the security community – even though he tries to imply otherwise.
Anyways, the only other thing I wanted to address was Timeless Prototype’s claims that vulnerabilities are only found where researchers are looking. This isn’t true. Anyone with a willingness to learn and the ability to grasp the information, and an understanding of programming, data types,etc can find vulnerabilities. 0days are found by the bad guys all the time – that’s why the network security industry exists. And when a blackhat finds a vulnerability, he isn’t going to tell anyone about it, or warn the vendor. She or he is going to quietly exploit it to break into protected computer systems. Disclosure beats the hell out of that alternative. The bad guys are always looking, just like the good guys. Fundamentally, we aren’t even very different at all except for one thing – whitehats don’t break the law. Reasons may differ, but I’d say mostly it’s because most whitehats discovered that they could ply their trade legally without having to worry about federal prison. For a whitehat, ‘hacking’ does not equate to breaking into protected computer systems owned by other people. It’s still just as interesting. Maybe even more so.
Sinden Lucks
Oct 25th, 2009
I’ve been in TCP/IP security and networking for years. There is no such thing as true security when opening a port. There are “levels”, and arrays of “levels”, achievable, but the only true security is an unplugged machine setting in the closet. Nothing has changed, it’s always been that way. If you are looking for security, you would look at the various “levels” that could be achieved using what we have with the old TCP/IP technology. It’s all about the packet, it’s all about handshaking. Nothing has changed. Security is not a product. It’s a continued effort. Any any smart teenager with a packet sniffer can do damage if that is the intention.
I don’t take many posts seriously that talk about ex griefer(s) etc.. and the security of Second Life. Second Life itself was hacked just a few years ago and many had to change their credit card numbers. It’s just par for the course. And we cannot blame companies who open the ports and work continuously at keeping an eye on the connections and code deficiencies. There are plenty of issues and areas we can look at to be discouraged and, in some cases outraged with in terms of Linden Lab and Second Life.
I’m with “A guy” the whitehat above on this one. When looking at how fine a line there is between “right and wrong” in security, it’s very tempting to be on the other side at times. But after 20 years, I’m still managed to learn and not fall over that line. It’s a great way to be, and the right avenue and perception to take when speaking of security and security related matters.
I had someone crack my opensim installation when teleporting from the Linden grid to my own. I just laughed. It must be real pleasing to the idiots to take a jab at someone enjoying the platform, alpha or not, running on full open ports without a single layer in place. And then bragging they did it just showed me how immature and uneducated they really are.
Security = Continual code analysis and multiple layers of checks and balances and the willingness to not step over the “whitehat” line.
Jumpman Lane
Oct 25th, 2009
plastic duck was a gawd! turdlycodec remains as ever a chump. ol’ dirt face phil got a nice dump lmao but my pool is cooler than his. nice story pix!
Darien Caldwell
Oct 26th, 2009
“independent security consultant” sounds suspiciously like “unemployed basement hacker” Hmm?
Deadlycodec
Oct 26th, 2009
>”independent security consultant” sounds suspiciously like “unemployed basement hacker” Hmm?
Maybe to you. But I have a pretty serious medical condition, remember? Someone disputed it, but I posted damning evidence in response to youtube so I’m pretty sure you’re not questioning that. I was amazed that Prok did. I don’t even have to work if I don’t want to. And some might even argue that I SHOULDN’T be working, but I enjoy learning about computers, network security, and how things work. That’s what this stuff entails. You can’t find flaws in a given system without understanding how it works, at least on some level. And it’s challenging.
I have been offered a position with a consulting firm, but I’d have to relocate to the D.C. area and that’s a difficult decision to make. Not sure that I am going to accept. Anyways, it isn’t like I couldn’t write for the Metro Spirit if I still wanted to. Tom is now a producer at WBEK-TV and has his own tv show called dividedcity.us which they also post segments from on their website (the url is the name of the show). I have maintained ties to the Metro Spirit’s current editor. I talk to her on facebook on occasion. Hell, my best friend is her brother-in-law. I didn’t like what Portico did to Tom, but I didn’t hold it against the people I knew at the newspaper. Truth be told, I’m not even privy to the details. But I’m not interested in working for them anymore on principle.
We are also lacking in basements here in the south. Anyway, I dunno about you, but I happen to think that there is nothing wrong with someone in my condition wanting to spend time doing something productive. I spend enormous amounts of time studying and absorbing information, speaking to interesting people,etc,etc. AND I get to hack and perform a public service while doing so. That’s precisely what disclosure is. It also educates. Other people get to learn from it and problems get fixed. Not to mention that it’s all pretty neat. I’ll make no apologies. Life is way too short. You can waste yours, but I’ll spend mine doing what I love. No regrets from here on out. I try to live by that these days.
Miki
Oct 26th, 2009
“DeadlyCodec’s analysis” … *lol*
lol
Oct 26th, 2009
@Miki
What about it? The people should know if there is something wrong with it, or if it’s inaccurate. So shoot. I’m assuming you won’t reply to this, since if you could have disputed what was said in a convincing fashion you’d have already done it. The proof is in the pudding, as they say. The pudding, in this case, being compulsory client updates.
makomk
Oct 31st, 2009
“Anyways, the only other thing I wanted to address was Timeless Prototype’s claims that vulnerabilities are only found where researchers are looking. This isn’t true. Anyone with a willingness to learn and the ability to grasp the information, and an understanding of programming, data types,etc can find vulnerabilities.”
Yep. The one remotely-exploitable buffer overflow in the Second Life client I’m aware of was discovered accidentally by someone reading the source code. (It’s long dead, thankfully – the last vulnerable version is now far too old to be able to connect to the grid.) Now, actually going from there to an exploit is harder, of course.
derf
Nov 21st, 2009
Secondlife is compiled with /gs. Idiots.
Deadlycodec
Nov 21st, 2009
@derf
/gs only applies to Second Life when compiled with visual studio, a windows application. Here is a nice little summary of the SafeSEH crap, which, like every other protection mechanism, is less than full proof:
“Flipping a single compiler switch will not make an application secure. It can help make an application more secure, but security vulnerabilities come in many different forms. Overruns of stack-based buffers are an important class of security vulnerability, but they are far from the end of the story when it comes to the techniques that hackers will use to attack an application. Despite initially appearing relatively harmless, heap-based buffer overruns are now known to be an exploitable vulnerability, and other attacks like SQL injection, cross-site scripting, and Denial of Service can all happily succeed against an application that relies on /GS for security.”
It’s just fucking Data Execution Prevention aka DEP, which can still be defeated.
“To use the formal terminology that has been adopted by Microsoft, /GS and SAFESEH are examples of software-enforced data execution prevention (DEP). Software-enforced DEP also can be complemented by hardware-enforced DEP, in which the processor will refuse to execute instructions if they are located within a memory page that has been marked as non-executable. Windows XP SP2 and Windows Server 2003 currently support these technologies, but few shipping processors have No Execute (NX) support. AMD and Intel have high-end offerings in the 64-bit world with NX technology, and future 32-bit processors may also ship with these security enhancements.”
OH WAIT, DOES THIS MEAN THAT DERF SHOULD LURK MOAR?
http://www.ngssoftware.com/papers/xpms.pdf – explains a few methodologies for defeating this mechanism. Now, go read up on stack protection mechanisms and when you have the expertise, THEN come back and argue with me, kthx.
Deadlycodec
Nov 21st, 2009
FYI that ngsoftware paper was on ret2libc attacks, and doesn’t really take into account stack canaries,etc. in the most modern xpm implementations, however, it is still possible to defeat it and you’re still an imbecile for googling a compiler switch and claiming it totally mitigates memory corruption bugs without doing any further research. Here is a better paper:
http://www.uninformed.org/?v=7&a=2&t=pdf
Also there is a really good paper by Leviathan Security called Exploitation Techniques and Mitigations on Windows, but you’ll need to find it yourself.
Simply put, these sorts of mechanisms don’t stop attacks, they just tend to make them a little more complicated. Every mechanism that has been designed, has gradually been defeated. That pattern has been pretty consistent, and will continue to be.
Deadlycodec
Nov 21st, 2009
@derf
And here is more on the /gs switch:
http://www.symantec.com/avcenter/reference/GS_Protections_in_Vista.pdf
Once you understand how a system works, finding ways to circumvent it isn’t so much of an issue. A minor obstacle.
Anyways, I specifically stated that this particular instance didn’t appear to be exploitable as it were. So what exactly are me arguing about again?
Deadlycodec
Nov 21st, 2009
Not only that, but without actually downloading the binaries and running them in a debugger, how is it even possible to tell what protection that switch will provide, if any? I say this because this protection is dependent on which version of Visual Studio is being used to compile the binaries that everyone is using, which are downloaded from Linden Lab’s servers – people don’t usually compile the viewer themselves.
I’ll correct an earlier statement I made. The /gs switch and SafeSEH are not synonymous. It may still be possible to attack via structured exception handling, which is unprotected by that switch at least in older versions of visual studio (I haven’t checked the newer ones) in which an additional compiler switch must be added to enable this added protection. Furthermore, gs does not protect all functions and if it isn’t used properly may not provide very much protection at all. Additionally, how are the libraries that Second Life uses compiled? They contain code (duh!) that is a part of the viewer too and if those aren’t completely secure, they may present an additional attack vector. A perfect example would be that Quicktime vulnerability discovered by Dino Dai Zovi awhile back. See here:
http://securityevaluators.com/content/case-studies/sl/
Now, I am satisfied that I have sufficiently argued my point. And I do it with my name behind it. So I’ll be back if and when you can find something else to be smug about but somehow I doubt you’ll find anything very compelling. Later.
derf
Nov 21st, 2009
I am reasonably convinced now that you didn’t find anything cool. I had missed the comment that a “particular instance didn’t appear to be exploitable as it were.” Thanks
Deadlycodec
Nov 22nd, 2009
“I had missed the comment that a “particular instance didn’t appear to be exploitable as it were.”
And if you were such an sooper awesome haxzor, you could have figured that out all by yourself! I mean, I am assuming that you read my blog post, since you mentioned the /gs flag which implies you knew it was a stack overflow. That tidbit wasn’t mentioned in this piece. Now, if you had read that blog post then there is no way you could have mistaken it for an exploitable vuln. I said it clearly several times.
Then again, you come across like a code kiddie who pretends to know more than he does, citing the /gs flag as though it mitigates stack-based overflows in their entirety, or maybe you assumed it mitigated all memory corruption bugs. So either way, that kinda makes you dumb. If anyone is paying you to do security for them, they’re in for a very rude awakening with that level of expertise.
BTW, here is yet another paper that shows weaknesses in the Buffer Security Check option from Visual Studio:
http://blogs.technet.com/srd/archive/2009/03/16/gs-cookie-protection-effectiveness-and-limitations.aspx
Those are CVE’s that impacted widely used software – the vulns are very well known. And this paper doesn’t actually detail methodologies for bypassing the mechanism, but rather exposes some fundamental flaws in the system that left critical parts of code unprotected, which allowed for many, many, computers to be compromised. There are even ways to bypass /SafeSEH with /gs protection.
Deadlycodec
Nov 22nd, 2009
And as someone who is actually experienced in finding vulnerabilities, I have to beg to differ on the coolness factor. For one, for a hacker picking something apart to understand how it works is always cool – that’s a major part of the ideology on which the subculture is based. It isn’t just about breaking into computers, legally or otherwise. It’s about exploration, knowledge, and learning – the very things that others have even heard me describe as part of the meaning of life. Fact is, I enjoy what I do with or without validation and honestly most of the stuff I do these days is kept under wraps, which reinforces that point.
And secondly, sloppy bounds checking code (or any other insecure code) implies the presence of more sloppy and insecure code elsewhere, which may or may not take the form of an integer overflow, an off-by-one, and/or your standard stack or heap overflow, or any number of other vulnerabilities, not to mention the ever-common business logic error and client-side enforcement bug that we’ve seen pop up time and again in Second Life. Maybe even an exploitable null pointer dereference, though the latter is unlikely. In an application with this much code, that is a very reasonable assumption. Ask any researcher what he thinks when auditing code when he comes across a vuln, even one that doesn’t appear to be exploitable such as this, and he’ll tell you something similar.
The nature of your comments imply that you have an e-grudge and a Napoleon complex. Wouldn’t be surprised if you were Sapinski himself. If you are, at least you learned not to put your name behind comments that make you look stupid. That’s always a plus. Anyways, you don’t seem qualified to really be able to say much on this topic at all, so excuse me for not taking you all that seriously. I guess this behavior should be expected from a guy who lost his virginity at age 18 at SLCC of all places. Seems like rather than making your own name through your own deeds, you’d rather discredit and attack others which implies that you are relatively unskilled.
Azlø Bildcher
Jan 13th, 2013
“Deadlycodec”…(!!)
So much -v ultimately reveals your Homer’s elbow….
as does your overuse of ctrl c and ctrl v…..