Last week Sentrigo brought a security hole in SQL Server to my attention. The issue is simply that SQL Server stores passwords in clear text in memory, so it’s quite possible to sniff the memory to retrieve passwords of other users. That in itself doesn’t sound dangerous at first glance because you have to have system admin rights in the database to do this. However, there are two basic situations where this could be horrendous.
Because most users have the same password, once you gain access to this password, you’ve gained access to all the boxes that account is on. This works on only native SQL passwords, not on Windows passwords. This is because when you use a Windows account to log into SQL, you don’t give it a password; you only pass in your security token, and there’s no password to steal. With SQL passwords, however, you pass in the SQL username and password, and this combination is stored in clear text in memory.
The point of Sentrigo’s press release isn’t as much about the security hole as it's about Microsoft’s refusal to do anything about it. I contacted Microsoft myself and here’s what the company had to say:
Microsoft has thoroughly investigated claims of vulnerabilities in SQL Server and found that these are not product vulnerabilities requiring Microsoft to issue a security update. As mentioned by the security researchers, in the scenario in question, an attacker would need administrative rights on the target system.
An attacker who has administrative rights already has complete control of the system and can install programs; view, change, or delete data; or create new accounts with full user rights.
Sentrigo says this is an important issue, but Microsoft says it’s not. In my opinion, Sentrigo has the right idea, and Microsoft is putting blinders on. I’m not sure why it's so resistant to seeing the real issue, but even when I talked to Microsoft, the spokesperson seemed quite determined that the above was the company's final word.
Here’s why I think Sentrigo is right about this; it’s an issue of perspective. Consider these two scenarios.