« Worthwhile SQL Server Blogs | Main | Poor Man's Scripting Tip »

Security Non-Issue/Publicity Stunt

I keep seeing tweets about how Microsoft is ignoring a security flaw. One that involves a potential risk for passwords to be exposed.

I think the folks who found this problem are likely VERY intelligent. And I think raising this flaw was a good move on their part. And I don't think that they're guilty of a publicity stunt. I think folks like these are. I also think they're dead wrong – because this isn't an issue. 

How can Exposing Passwords NOT be a security issue?
At the heart of this problem is the fact that passwords for SQL Server Authentication users are stored, in memory, in plain text. Granted, that seems like a bit of a problem and I wouldn't be surprised to see it corrected some day (maybe in future service packs and/or future versions). But I certainly agree that it doesn't need any immediate attention. Nor, in fact, do I think it really needs any attention.

Why don't I care? Because in order to take advantage of this information, you would need to be a part of the Trusted Computing Base (TCB) on a server to gain access to these passwords. In other words, you'd either have to be running code as an Administrator or as Local System/etc. So, in other words, to be able to take advantage of this exploit, you'd need to be an administrator on the box you're targeting.

An Analogy
My kids all have bedroom doors that lock. My bathrooms all have doors that lock.

Those locks offer some great security – when you close the door from the inside, and turn the little knob inside the door-knob, you're locked in.

Sadly though, because my children (when they were smaller) were able to accidentally lock either their bedroom door or the bathroom door without being able to figure out how to unlock it, I've also got little 'keys' scattered in my house on top of door frames. And these keys are either nothing more than little thin slats of metal provided by door knob-manufactures, or cannibalized sardine-can openers. Point is: any parent with small children knows exactly what I'm talking about.

And in relation to this, what this security exploit is crying wolf about is analogous to saying that if thieves are able to break into your home, they might be able to unlock your kid's doors.

But what about…?
And as for any arguments that people testers or others might have admin perms when they shouldn't have, those are are all moot. If you trust those people enough to give them access to your systems at TCB level, or if you trust code enough to run it at that level, then you've got way bigger problems than the fact that code or a rogue admin might find out that Ted's password over in accounting is hotdog1. And if Ted's using that password everywhere within your enterprise, then he should be connecting to your SQL Server with Windows Authentication – not SQL Server Authentication. So this shouldn't even be a problem – and if it is, it's not because of this exploit, but because you haven't secured your system as you should. In other words, about the only time when using SQL Server Authentication makes sense is when you're letting web users or other applications access your system that can't (for one reason or another) use Integrated/Windows Authentication. And being able to discover those people's or application's passwords is a moot point.



Comments

Loading Comments... loading comments

Post a comment

Comments may be moderated.

The following pseudo-markup is permitted:
      bold : *strong*
      italic : _em_
      hyperlinks : [linktext|http://link.url.here]