Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SQL Server patch pros and cons

Are you afraid to patch your SQL Server systems? Installing a patch can bring your database server down and corrupt data. Yet, unpatched software leaves your system vulnerable to attacks by unruly insiders. IT security specialist Kevin Beaver examines the pros and cons of patching SQL Server.

I often come across DBAs and network administrators who are afraid to patch their SQL Server systems for fear of...

causing problems. There's a part of me that doesn't blame them. After all, SQL Server houses "the goods" and when the goods are disturbed, business tends to slow down and job security tends to drop. Images of shriveling up and fleeing even come to mind. The argument against patching is that the system is doing fine as it is and, of course, it's safe because SQL Server is "behind the firewall." The mode of operation is to let sleeping dogs lie – no need to upset the beast.

The problem is that many DBAs and network administrators aren't aware of just what can happen when vulnerabilities created by lack of patching are exploited by a trusted insider. This goes for SQL Server software, the Windows OS and other software running on the same host, such as VNC, backup software and IIS. Many claim that even if a serious vulnerability were present on their SQL Server systems, no one on their network would have a clue about how to take advantage of it. A logical argument, but that's not the point.

Fact is, all it takes is a trusted insider (or outsider via an unsecured wireless connection) downloading free security tools off the Internet, playing around with them a bit and then using them maliciously to gain full access into the sacred database system. BackTrack and, specifically, Metasploit come to mind.

With the right tools and the right amount of time – both of which are on the side of trusted insiders – anything's fair game. For instance, there are several known SQL Server vulnerabilities (fixed by patches of course) that are easily exploited using Metasploit and commercial alternatives for those who have access to them. This means that anyone with just a basic network connection can gain full admin-level Windows command prompt access to SQL Server systems. They don't even need a Windows or SQL Server login! Physical access to the network is all it takes.

The following screenshots are an example of how an insider can exploit the Slammer worm buffer overflow vulnerability on an unpatched SQL Server system. "Slammer," you say? Don't laugh, I still find SQL Servers vulnerable to it.

Figure 1: Using Metasploit to gain access to an unpatched SQL Server system's command prompt

 

Figure 2: Full admin-level access to SQL Server files is made possible

There are even more possibilities for gaining this type of access by exploiting other unpatched applications running on the same system. And this is just the beginning. Using vulnerability scanning tools, users can find other exploits specific to SQL Server, including privilege escalation, denial of service and access to the system table. Again, this is all because the recommended patches haven't been applied. No external firewall is going to keep these internal misdeeds from happening.

You've got to ask yourself what's worse: 1) installing a hotfix or service pack that brings your

More on SQL Server security:

 database server down (or even creates data corruption) for a relatively short period of time until it's backed out (or restored) or 2) presenting low-hanging fruit in the form of unpatched software for unruly insiders to exploit? Don't get me wrong, I've been burned very badly in the past by being too eager to patch Microsoft software. But that was years ago. Based on my experience, the quality of patches has greatly improved (albeit not perfect).

There is no great answer, but it boils down to a balance of risk and a matter of choice. In the end, I'd rather suffer through a botched patch install than face the consequences.

Envision yourself answering to executives, customers or regulators who are asking why countermeasures to a known exploit were never put in place after identity theft, data destruction or a related incident occurs. If a patch install creates problems, at least you were doing what was in the best interest of the business. You can't say that when patches are simply ignored. Heck, if a problem does arise due to a patch, at least you now have a good reason to push for a test environment that everyone knows they need but can't seem to justify having.


ABOUT THE AUTHOR
Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments revolving around compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He also created the Security On Wheels audiobook series.

This was last published in August 2007

Dig Deeper on SQL Server Migration Strategies and Planning

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close