The SQL Server Security Issue That Wasn't

By Michael K. Campbell

There's been a lot of hubbub lately about a supposed SQL Server security flaw. Normally, that would really get my attention. Instead, the more I hear about this so-called flaw, the more annoyed I keep getting. In fact, I'd even make the argument that those drawing the most attention to this flaw are actually advocating poor security practices.

Extra! Extra! Microsoft Ignores Security Risks!

One aspect that has helped propel this so-called risk into the limelight is the fact that Microsoft has known about this issue for over a year, yet has done nothing to address it. On the surface that sounds totally scandalous - especially when we're talking about security. But don’t forget that Microsoft learned an awful lot about SQL Server and security with SQL Server 2000. In fact, check out Secunia's comprehensive security advisories for SQL Server 2000, 2005, and 2008. You'll notice a trend where there's a decrease in the number of both advisories and vulnerabilities to the point where there are NONE listed for SQL Server 2008 (which is an impressive feat).

Given that Microsoft appears to be taking security very seriously based on their track record with Secunia, both in terms of total vulnerabilities and in terms of response times, it doesn't seem to make much sense that Microsoft would become cavalier about a potential threat. That's because, in this case, there isn't one.

Anatomy of an Issue

At the heart of this security issue is the fact that passwords for SQL Server Logins are stored, in memory, in clear text. So, each time a user or application uses a SQL Server Login to access a server, once they log in, their passwords will be stored (in memory) in clear text. If the application or user uses Integrated (or Windows) Authentication, then there's no issue. Likewise, the persisted, or stored, passwords for SQL Server Logins aren't stored in clear-text - so this issue only applies to logged in users using SQL Server Authentication.

However, since memory can only be dumped or scanned by users or processes with administrative privileges, the only two attack vectors this problem really needs to consider are rogue administrators or hackers that have managed to take total control of your box.

The security firm that found this issue, Sentrigo, has disagreed with Microsoft's decision to not issue a fix for this issue. Microsoft bashers and other pundits have picked up on this issue, and the entire thing has devolved into a bit of a PR circus. I think Microsoft is spot-on in not doing anything. Three reasons come to mind.

Reason 1: It's a Non-Issue

First of all, this really is a non issue. If you can't trust your administrators with passwords or data, then you're screwed—pure and simple. It's one of the immutable laws of security (see law #6). Likewise, if hackers are able to run code with escalated, administrative privileges, then they've managed to take complete control of your system. They're then free to do what they want with your data, install whatever they want, and create or modify accounts as they please.

More importantly, even if SQL Server did NOT store these passwords in clear text within memory, anyone with administrative permissions would STILL be able to hook the authentication process and gather passwords as they were being authenticated. The fact that SQL Server stores them in plain text just makes the task of gathering them that much easier. But to get to the point where that matters, your entire system has to be compromised. So even Sentrigo's free solution to “fix” this problem doesn't. It just mitigates the issue by making hackers or administrators work a bit harder if they want your passwords on a compromised system.

Moreover, worrying about processes with administrative privileges being able to scrape passwords is kind of like arguing that TVs should have passwords to prevent thieves who break into your house from seeing what kind of television shows you have recorded on your DVR or Tivo. Granted, I'm pushing that analogy a bit far, but the point is: if you have malicious users or code running at this level, those passwords SHOULD be your last concern (as I'll touch upon in a second).

Reason 2: Patches are Painful

If this WERE a true security vulnerability, Microsoft would NEED to issue a patch. If past experiences are any indicator, there's a good chance that this patch would be a pain in the butt to install, and would result in down time, scheduling head-aches, and so on. Even if Microsoft were able to streamline the patching process, there would still be issues of scheduling and down-time.

Stated differently, patches are expensive. By not issuing a patch for this issue, Microsoft isn't just being lazy or cavalier: They're recognizing the impact that this would have on systems administrators and DBAs. That said, if a patch were warranted, then the expense, pain, overhead, and cost of patching would be a simple casualty in the war on security, and I'd be clamoring for it. But since this isn't a real vulnerability, I'm glad Microsoft is making the right move and not crying wolf in this case.

Reason 3: Blaming Microsoft Draws Attention Away from the Real Problem

Sentrigo is right to point out that there are legitimate concerns about end-users re-using passwords across multiple systems. Sadly, not only is this a reality, it's also a security worst-practice. However, issuing a solution that lets organizations persist in the use of this worst-practice is not only short-sighted, it's dangerous and, interestingly enough, it's probably making things more difficult on your end-users.

For example, if you're making Clive in Marketing use SQL Server Authentication to log into a CRM as well as a TimeSheet program, you're not only engaging in a security worst-practice, you're making Clive's life harder. Not only does he have to log into his desktop when he arrives at work, but now he has to log into different applications to get his work done. Multiple sign-ins are a pain for end-users to deal with. In fact, I'd argue that using multiple sign-ins like this is a key contributor to why people use the same passwords in multiple systems. Even worse, people who get sick of jumping through different logins on different apps and take shortcuts with their credentials are the same kinds of users prone to leaving their logins laying around on sticky-notes when they get tired of remembering them.

So, yes, in cases where your TimeSheet server gets compromised, it's fair to say that hackers or bad administrators could then use Dave's credentials to hack into your CRM. But if you're susceptible to this kind of security problem, then you're doing everything wrong and the fact that SQL Server is storing your passwords in memory is the last of your problems.

But if you're using Trusted (or Integrated/Windows) authentication, then not only are you following the security best-practices outlined by Microsoft, you're also doing Clive a favor. Because once Clive logs into his desktop, the single-sign on nature of Kerberos authentication makes it possible for him to access the TimeSheet application and the CRM application without having to explicitly log in. Moreover, because Clive now just needs to remember one password instead of three, it's easier to get him to pick a secure password that he's more easily able to remember, and he’s less likely to write down somewhere. It's also easier for IT to stress the importance of good security practices because end-users don't need to juggle those practices over as many accounts. That, and the issue of SQL Server Logins being stored in memory in plain text is no longer an issue.

As Microsoft's security guidance states "As a best practice, we [Microsoft] recommend that you use Kerberos whenever possible for connections to an instance of SQL Server". Using SQL Server Authentication for some distributed web apps and other applications can make sense. But using SQL Server Authentication within your business or enterprise doesn't make sense. Therefore, releasing a “patch” that encouraged administrators to continue with this worst-practice would actually have been a bad move on Microsoft's part.

And while I can't blame Sentrigo for taking advantage of this “problem” to help market their solutions, I do take exception with their approach of offering a “patch” that lets businesses and IT Pros continue this security worst practice as if the only real security problem were something that, in reality, is a security non-issue—while bigger security issues go unaddressed.