July 14, 2015 at 9:05 pm
Comments posted to this topic are about the item MS15-058: Vulnerabilities in SQL Server could allow remote code execution
July 15, 2015 at 6:44 am
For curiosity and prevention, what does the "special crafted" (as MS says it) query looks like? I often see SQL Instances not patched (not under my control / jurisdiction) so having an idea of what it looks like could help to identify weird behavior or at least to know what to look for.
Thx
July 15, 2015 at 6:59 am
Thanks for the heads up.
July 15, 2015 at 8:44 am
Megistal (7/15/2015)
For curiosity and prevention, what does the "special crafted" (as MS says it) query looks like? I often see SQL Instances not patched (not under my control / jurisdiction) so having an idea of what it looks like could help to identify weird behavior or at least to know what to look for.Thx
I have not seen this. I suspect it's a query with some hex in it, though the KB mentions a call to a virtual function. They typically don't publish the query as people might run it on their instances (or others).
July 15, 2015 at 10:30 am
I have not seen this. I suspect it's a query with some hex in it, though the KB mentions a call to a virtual function. They typically don't publish the query as people might run it on their instances (or others).
Still, going deeper I do now know that it is related to two things:
One comes from Transactional replication
and the other one (exploit) comes from database name, schema name and data within it.
I feel more safe knowing this than just a "virtual call". I know more what to be aware of.
- The first one, it's not always on and most of the time it's scripted or setup by a DBA
- The second, not very easy to cover / hide
For both of them a DBA could easily exploit those two vulnerabilities, but at the basis, a DBA often has all the rights in SQL Server (and often on the box for perfmon and the like also) so it would be pointless for them to do such attacks other than preventing non-DBA to do it.
The other question I have in mind is: in what circumstances that person found this vulnerability?
July 15, 2015 at 10:50 am
Megistal (7/15/2015)
The other question I have in mind is: in what circumstances that person found this vulnerability?
I'm not sure what you mean? Do you mean how was this reported?
This is a patch for an issue Microsoft has released and acknowledge. How could it occur? If anyone has access to a SQL Server, including SQL Injection through an application, and they submit a query.
That means anyone who can access your SQL Server could potentially exploit this.
Patch your server.
July 15, 2015 at 11:02 am
I'm not sure what you mean? Do you mean how was this reported?
No.
The first time it was discovered, if not by someone who deliberately search to find issues (QA, hackers and the likes), it was within a valid, good intentions business case which was under development.
One of the vulnerabilities include names and data. Before this vulnerability was known, what justified those (probably weird) names for databases, schemas?
We will never knows, just wandering, base on names assumption, how to go into that direction to fall into the issue.
July 15, 2015 at 11:19 am
So, I anticipate the following happening:
Me: Hey boss, Microsoft has released a security patch. Steve Jones recommends we should patch all of our servers.
Boss: LOL
As a SQL professional, I get it when when Microsoft says "hey everyone, heads up!!", and not need a whole lot of supporting data. Boss-man however is going to have a lot of questions, and I need to be able to explain what the nature of the risk is, and if we even need to be concerned.
I've read through the descriptions provided by Microsoft and it doesn't give a whole lot of details on what exactly is being fixed:
"This update resolves vulnerabilities in Microsoft SQL Server that could allow remote code execution if an authenticated attacker runs a specially crafted query that is designed to execute a virtual function from a wrong address. This leads to a function call to uninitialized memory."
Huh???
I need ammo to justify taking the time and resources away from all my other work and patching our servers.
Can anyone elaborate further on this?
Thanks,
Mike
July 15, 2015 at 12:29 pm
It's as vulnerable as before. How likely is an attack?
Depends on your level of SQL Injection vulnerability as well as how many people (outside of employees) can send a custom query through to the instance.
I think in many cases, it's not a big deal. If you have potential issues, then you'll want to patch sooner.
July 16, 2015 at 5:54 am
It is getting quite confusing of what patches to apply to each different version and CU version of SQL Server. We have so many versions and at different releases here.
I don't know if I agree with putting other fixes into a security patch. I guess that can be debated until the end of time though.
July 16, 2015 at 7:33 am
A point to be aware of.
The "fix" will download as part of Windows Updates.
I usually download Windows updates automatically to Dev servers but I apply the update package manually then schedule a re-boot for a convenient time.
This particular patch APPLIED automatically when it was installed. The patch shut down ALL SQL Services (Engine, Agent, SSIS) on all Instances and then restarted them. All were from "MsiInstaller" except one from "RestartManager" about SQL not accepting new connection requests.
The Windows Updater puts a lot of noise in the Event Log but I copied a number of extracts (see below). They are in order of appearance but they are a very small selection of entries.
I did not see any warnings about this behavior in the Vulnerability Announcement, the KB Article, or the patch Download Page. I fully expected the requirement to restart SQL and/or Reboot the server but I did not anticipate the AUTOMATIC SQL Restart. (My Devs were happy ;-))
Product: SQL Server 2008 R2 SP2 Common Files - Update 'GDR 6220 for SQL Server Database Services 2008 Common Core (64-bit) (KB3045316)' installed successfully.
Windows Installer installed an update. Product Name: SQL Server 2008 R2 SP2 Common Files. Product Version: 10.53.6000.34. Product Language: 1033. Update Name: GDR 6220 for SQL Server Database Services 2008 Common Core (64-bit) (KB3045316). Installation success or error status: 0.
Windows Installer reconfigured the product. Product Name: SQL Server 2008 R2 SP2 Common Files. Product Version: 10.53.6000.34. Product Language: 1033. Reconfiguration success or error status: 0.
SQL Server cannot accept new connections, because it is shutting down. The connection has been closed. [CLIENT: 192.168.1.141]
Windows Installer installed an update. Product Name: SQL Server 2008 R2 SP2 Database Engine Services. Product Version: 10.53.6000.34. Product Language: 1033. Update Name: GDR 6220 for SQL Server Database Services 2008 Core Instance (64-bit) (KB3045316). Installation success or error status: 0.
July 16, 2015 at 7:37 am
Well we've started updating our environments. It's quite a long update. We'll try it for a while before doing it in production.
July 16, 2015 at 7:43 am
Hi Ya Ten Centuries.
Unfortunately it is a complex process. As I mentioned in another reply the patch came down with Windows Updates. It is very time consuming to sort through the list of "updates", track down each KB, attempt to decipher the issue and determine whether to apply it or not.
We don't have the staff resources to do that level of diligence.
Unfortunately, unless you have a superior hardware/firmware configuration management process in place you pretty much have to handle each server individually.
IMO, in a one or two person shop your Windows Update policy just about has to be either "apply them all on trust" or "don't apply them at all".
Our Dev and Production Servers are almost identical but there have still be several occasions where the Updates applied to Dev with little or no unexpected events and then caused a problem on Production.
As the King said to Anna, "It is a puzzlement"
July 16, 2015 at 8:06 am
Markus (7/16/2015)
It is getting quite confusing of what patches to apply to each different version and CU version of SQL Server. We have so many versions and at different releases here.I don't know if I agree with putting other fixes into a security patch. I guess that can be debated until the end of time though.
I tend to agree, but think about this. Every patch gets built onto other branches of stuff. I think here they included some fixes that were likely to go out in the next CU and might have been already too implemented to undo in order to get this patch built.
I feel this is a very complex process, as there's a GDR and QFE, which means two builds for each branch. One off the base of RTM/SP and one at the current CU. It's certainly confusing and problematic, but I also know the security patches are one-offs, and we see few. We got one last year (MS14-044) and this one. A few fixes aren't overly concerning for me, but they better be well tested.
July 16, 2015 at 8:24 am
HEY ALL!
Be aware that this patch is considered a HIGH SECURITY RISK and because of that Microsoft has the ability to install and restart your SQL Server (or your Windows Server) without your permission and knowledge under certain conditions.
According to our IT department all downloads and installed patches go through a group policy and automation program. Why do I care? Our production server was taken off line yesterday when the download tried to install and failed because it had other patches waiting to be installed that required a reboot and reboots only happen on weekend maintenance windows. SO it restarted SQL all by its self at 3 pm in the afternoon! to finish this patch to SQL Server.
Just a heads up - let your IT department know this is totally NOT acceptable. :w00t:
Tim "the Trollman"
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply