So much -v ultimately reveals your Homer’s elbow….

as does your overuse of ctrl c and ctrl v…..

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.

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.

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.

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?

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.

/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.

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.