Who is to Blame for the SQL Slammer Virus?
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/bknight/sapphireblame.asp
Brian Knight
Free SQL Server Training Webinars -
The only problem I have with not blaming MS is it is their code. Sure the Admins, DBAs and networking folks could have taken proper steps to prevent/limit the issue. But the ultimate problem still lies with MS not properly sanitizing their code. They have for years suffered more issues from buffer overruns being found than should be. And the issue I have with that is they know better. Obviously the folks involved with the developement should hit those key points harder than anywhere else to make sure the code can stand against attack. Also, if the problem code is found in one major server or os application then it more than likely exists in others. So instead of waiting to see if someone else finds the flaw, why does MS not have stress testing group whos sole job is to find these issues before any thrid party company does. I say if MS would take more pride in writing code instead of bloatware (10s of functions that all do the same thing within the same app) then issues like these could be far more limited than they currently are. On top of that as pointed out a hotfix for this vunerability was broken by a later hotfix. So in that situation the DBAs and admins thought they had handled only to be let down after the fact. MS should be more carefull with the hotfixes and in that type of situation a company should have every right to recoup loses from MS for the false security that had been offered. There are just too many sides to this coin. But not matter what, MS is the key player in blame and it trickles from there.
-
you mentioned a free product from eeye.com, but not the name. Unfamiliar with their products, i could not find the one you were talking about. Could you let us know what it is?
-
I found the article more on target then off. Microsoft created the problem some time back. Microsoft corrected the problem. Some heard the call, saw that the wolf was at the door and installed the fix. Others heard the call, saw the wolf and were in the process of slamming the door but they got hit, others were not aware and got hammered.
The article rightly identified that there are companies out in the wild that have little time to spend on protectection or prevention, and are willing to take the hit if it comes, they do not give us the time or monies to have adaquate staff on hand to preview, patch, and prevent the intrusions that we face.
It would be too easy to say that we are over worked, understaffed, and years behind the curve in training. It is harder to say that in the setting of priorities with the resources we have that some had not gotten there yet, but were working on it.
But the hardest thing to say is that the problem existed, there was a fix for it, and it did not get done.
Not all gray hairs are Dinosaurs!
-
It's on both sides. There will always be bugs in code, so blaming MS for writing bad code isn't really right. Everyone has bugs and MS released a patch for this bug last July.
However, they then messed things up with a later release, which is their fault.
They might also shoulder some of the blame for not having an easier way to patch systems. Copying files isn't acceptable for a windows system these days.
I would, however, place the blame for the other worm more on MS's shoulders. They shouldn't even allow blank passwords. If it breaks your app, tough. Fix it.
We do have to shoulder some of the blame. My company got hit hard, lots of which was the result of MSDE and SQL installs that are controlled by development, and other groups who don't want to patch their systems or won't allow me to do it.
BTW, if you have 1434, 135, 137, 139 open to the Internet, you should be fired.
Today.
Steve Jones
-
<rant>
The SP2 hotfix works... just a patch released after the hotfix had old files and if you let them overwrite, you lose the security patch. Great, right? The article on the hotfix in question says don't overwrite! Well, that begs the question, why not fix the download?
As for SP3, it does break DTS with text files and rows over 255 characters. We're seeing that problem ourselves. I don't remember this being an issue during beta testing. I wonder if anyone took a look at it. I didn't, so I'm just as culpable.
Who to blame? It depends on how far the admin went. Did the admin apply the hotfix that removed the patch? Then MS is to blame. If they didn't install MS02-039 or the roll-ups thereafter, there's not too much excuse. Copying files and running scripts should be within the capabilities of any DBA or system administrator, but there's a lot of folks screaming it's too hard. I don't get it!
</rant>
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
quote:
you mentioned a free product from eeye.com, but not the name. Unfamiliar with their products, i could not find the one you were talking about. Could you let us know what it is?Hi! THe product is here: http://www.eeye.com/html/Research/Tools/SapphireSQL.html It's their free version also on their homepage.
Brian Knight
http://www.sqlservercentral.com/columnists/bknight
Brian Knight
Free SQL Server Training Webinars -
Who says that it has to be MS, or the DBAs, or the Network Admins, or all three at fault (see the latest poll)? Whenever there is a virus/worm/whatever, there will quickly be finger-pointing. Yes, MS shouldn't put out products with bugs; but then neither should we. Code bugs happen - get used to it. Yes, DBAs should have applied the patch or the service pack; but not all DBAs are allowed to apply upgrades/SPs/patches without the client fully testing them - I know I can't. Yes, the network admins should have shut off UDP 1434 - but network admins have to look at the big picture and the only way to really secure a network is close ALL ports and it can't be done; so is it their fault they missed one port out of them all?
My point here is that sometimes there are circumstances beyond our control and bad things will happen. When they do, we will be scrambling to fix the problem - that's why backups are so important. I wonder how many DBAs, affected by the worm, had current backups of their systems.
DO YOU?
-SQLBill
-
The best part of this article is the 'I TOLD YOU SO!!!!'. This has happened so many times from a DBA's perspective, whether it is a potential security risk or just going out of support, many times it is difficult, at best, to convince users/management that system upgrades MUST be done and done on a regular basis!!
-
quote:
It's on both sides. There will always be bugs in code, so blaming MS for writing bad code isn't really right. Everyone has bugs and MS released a patch for this bug last July.Hey Steve just wanted to add here that this issue has shown up in serveral products before, not just SQL. So by now they should have a clue what to look for and in this case have been better at preventing in the intial release. Also, if you read the article on ways to prevent issues with code on the MS site which had a link here they very blatantly discuss Buffer Overruns http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityTips/default.aspx and was even the number 2 item. So ultimately they have know, should have known and been more cautious with this particular typ of issue. So yes I blame MS. However once the patch was released and they made the public aware then yes it is then End Users error for not follwoing thru. But those who did and got hit due to a later issue was a major screwup on MS's part since they don't have apparently proper revision testing on Hotfixes.
Like I have said before. I take Hotfixes with a grain of salt as they do not go thru a stringent BETA testing as do SPs. So I love it when my Company heads say install an Hotfix which they have not checked because they are still testing the SP. SPs may still cause issues but are less likely than Hotfixes to do so for that simple fact.
-
I'll grant that the hotfix record of Microsoft has been less than stellar. Case in point: uPnP and RDP patches that blue screened systems and the latest memory leak patch for SQL Server 2K that undid the security patch from MS02-039, the buffer overflow in the listener service.
However, if the system is exposed to the Internet and it's running SQL Server, it has to be kept fully patched. I don't see any way around this. I know there are some legitimate business reasons for having SQL Server unshielded by a firewall (i.e. some B2B stuff), but generally, it shouldn't happen! In any case, you would want to use a non-standard port and encrypt the communications... which means the other guy should know what port to point to, rendering the listerner service unnecessary (meaning you can block UDP/1434).
The reason I can't entirely blame Microsoft is because of some of the configs people were asking question about. For instance, in one of the webinars, someone asked how to block ports TCP/1433 and UDP/1434 for a SQL Server they had multi-homed! That's right... one NIC was attached to the Internet, the other to their internal LAN. The SQL Server in question (if I understood the person right) only needed to be seen by the internal LAN. With this kind of configuration, the blame can't entirely be put on Microsoft. This is a big no-no in perimeter security.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
Nope, didn't say you could blame for ID10T errors (
). No offense to those who made this type of mistake. -
What Microsoft released prior to the Slammer crisis was little more than a "Here's a patch so you can't blame us" release. I manage over 140 SQL Servers (Not including untold numbers of MSDE machines handled by our desktop team) with *one* other person. Without an automated process to apply the patches after hours, it would take two people around 20 hours to get the hotfixes out there; and that is only if everything goes just right.
The corporate firewall folks are not the reason the Slammer worm got into our site. It didn't come in from the internet; at least not directly. Some poor Joe with MSDE on his laptop connected to the corporate network via VPN was the initial victim. And all this happened while the security and desktop teams were implementing firewall software for VPN users.
Now, in Microsoft's defense... Buffer overruns are *not* just a Microsoft problem. I see a lot more security alerts from non-MS products (Mostly Linux and UNIX OSes and packages) in the Enterprise arena and they are nearly all buffer overrun vulnerabilities. Software developers are human too.
The moral of this story, as stated in the article, is that you can't blame any *one* person or group but some participants in the game deserve more blame than others. I am not lazy; if I were, I wouldn't have a job because companies can't afford laziness in this economy!
Bryant E. Byrd, MCDBA
SQL Server DBA/Systems Engineer
Intellithought, Inc.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
quote:
Where MSDE can be especially dangerous is when a user takes their laptop home with MSDE on it, becomes infected with any virus and then brings it back into your internal network and behind all of your firewalls. No firewall rule will protect you from that sort of event.Brian,
You wrote an excellent article. Based on it, I started searching for MSDE in our shop with the eeys.com utility and found way more MSDE than I ever imagined.
Everyone,
Here is the problem...
When I try to apply the "Desktop" flavor of SP3 (i.e., extracted from SQL2KDeskSP3.exe) to MSDE 2000 (running Windows 2000 SP3), I get "The instance name specified is invalid." I get this error even after installing MDAC 2.7 Refresh on the machine.
Am I missing something? What could keep this install from working?
TIA
). No offense to those who made this type of mistake.Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply