Slammer Worm Slams Microsofts Own 528
MondoMor writes "Microsoft's forgot to patch some of its own servers to protect it from the months-old vulnerability exploited by the Slammer Worm, reports C|Net. Oops. Apparently Redmond's network was hit pretty hard. Just goes to show that no matter who you are, you'd better keep your apps patched." Update: 01/29 01:59 GMT by T : And if you're running systems which might be affected, take note: whitehorse writes "The Microsoft KB article for the Slammer patch found here has an incorrect URL for 'Download the patch' referring to KB Q316333 which is only a handle leak fix. The real patch may be found later in the article."
SQL Server (Score:5, Interesting)
Re:SQL Server (Score:5, Interesting)
Basically, the idea is that by running "ancient" versions of software products, the script kiddies are completely thrown for a loop--their collections of 'sploits only work on more recent versions of code.
Not that I advocate it, of course, but you made me think about it.
Re:SQL Server (Score:4, Insightful)
It doesn't work, at least not for Microsoft's products. You and grandparent post forgot the Microsoft Support Life Cycle [microsoft.com], say Windows 98 and NT 4.x will be entering "Non-supported phase" after June this year, Windows 2K even earlier, March.
Granted, SQL server 7.0 is still under the coverage of normal support til March, 2004, and if you happened to be a premium customer, they the period can be extended to 2006.
However, do not forget when a product is desupported, Microsoft will not take care of new problem found in it. No service patch, no enquiry. No MS reseller would dare take up the maintenance. They'd only offer you one option thereafter: upgrade.
Keep using the desupported products? Sure you can, but can you bet your career on a desupported product? You're welcome to do so as they can have a convenient target to blame when shit happens.
Actually No (Score:4, Informative)
While troubleshooting an issue related to the patch w/ MS phone support, the technician told me that 7.0 is not affected and the bulletin was incorrect.
It is entirely possible he was misinformed though.
Comment removed (Score:4, Informative)
hahaha - there's justice for you (Score:3, Funny)
"That vulnerability is completely theor...oh shit!"
Grounds for legal action? (Score:4, Interesting)
They release fixes that people have been so conditioned to avoid that they even do so themselves. It hardly seems to be a fix if nobody will touch it with a ten foot pole.
Which would you rather have? (Score:5, Interesting)
The first choice would lead to a lot more work. The second choice would have automatically installed
Power is like entropy. It always seeks to increase.
Re:Which would you rather have? (Score:5, Insightful)
That argument is an example of a logical fallacy called "bifurcation" - presenting two alternatives as if they were the only two alternatives, when in fact more may exist.
Somehow I keep my Debian system updated with the latest security patches without much effort, and without being forced to accept patches I don't want.
Re:hahaha - there's justice for you (Score:3, Insightful)
You don't suppose this will convince them to finally switch to OSS, do you? I haven't seen my MySQL boxes taking down the Internet lately!
(Ok, ok, that was low.. ;) )
Zoiks! (Score:5, Insightful)
Re:Zoiks! (Score:5, Informative)
Re:Zoiks! (Score:5, Informative)
There isn't only no way to get SQL Server patches from Windows Update, but (as the parent mentioned), the steps required to update SQL Server and the Desktop Engine (MSDE) is a royal bitch and some.
For example, to apply any hotfixes or cumulative patches for SQL Server 2000, you must download the package, extract it, backup the SQL Server install directory and databases, manually copy over DLL files and other updated binaries, execute the SQL query files included in the patch (one at a time, in a certain order... MSDE users need to use the command line interface for it since there is no GUI provided), then pray that everything is okay and start SQL back up.
Re:Zoiks! (Score:4, Insightful)
Gadzooks! (Score:5, Insightful)
I agree, however...
Microsoft has argued for a long time that Windows is easier to administer (than UNIX/Linux), and that you don't need to hire an expensive, trained admin (which I assume they are referring to UNIX admins, but aren't MCSE expensive, trained admins, all jokes about the quality of MCSEs aside?).
So here we are with MS SQL Server, which is supposed to be an enterprise quality database system... but it has no intuitive interface for installing patches. So either we have a real DBA, who should know how to do these patches, or we have a power user to manage the database through a better interface to keep up to date on patches.
Either it's easy and you don't need an admin, or it's difficult and you do need a trained admin. SQL Server updates can't be as "complex" as they currently are if Microsoft is going to claim that anyone can admin a Microsoft server product.
Granted, they may not be making the claim that SQL Server is easy to administer, but what are the customers going to think? If Windows is "easy" (or so says the advertising), then SQL Server must be easy too! They both have little wizards to automate tasks, they both have a graphic interface for management...
That's the SP, not the patch! (Score:5, Informative)
Alot of sysadmins were waiting for the SP to be released before even approaching this one, just because the patching process is so complex. They just waited a week too long
Re:Zoiks! (Score:5, Insightful)
Relying on a vendors automatic update feature is no substitute for solid system administration.
Solid system administration is no substitute for solid systems.
Re:Zoiks! (Score:3, Interesting)
I heard this from our Windows admins at work as an explaination as to why we were hit.
And as someone mentioned below, it just takes one person with a laptop or a poorly configured firewall somewhere in the organisation to get hit.
Still, it's funny as hell that MS got shafted. Especially as they say that "If You just keep your system patched, its no problem. We can't be held responsible for what You don't do."
The Irony (Score:5, Interesting)
Re:The Irony (Score:3, Interesting)
Sorry. It's just a little funny.
Second, I was just thinking about how inefficient using a web site to update their products is. With XML-RPC and SOAP available, they could at least make a client-side app that optionally does this. Yes, XP has it. Why not make it available for all their apps?
Or is it, and I'm just in the dark?
Re:The Irony (Score:5, Interesting)
MS patches/service packs have a nasty habit of breaking applications, ESPECIALLY the SQL Server updates. Whenever they release another SQL patch, it takes us a very long time to approve it for use, and it almost always involves some recoding on our part. Repeat this process 20 times a year and it gets damned near impossible.
Re:The Irony (Score:5, Interesting)
I have come to dread every MS patch with a certain sense of dread. At least on the desktop you can build an image and test it with no real risk, but on production servers it's a total gamble, and I'm tired of bettig my ass (and personal life, and sleep, and job title) on Microsoft. Our SQL box is behind a firewall and no other SQL (developer or otherwise) runs in house, so I took a pass on this patch until the guys that code the payroll system have approved it. That might sound great until you know they are 3 guys who support 5 products (with multiple versions) and it takes them months to test anything.
I'm quite glad MS gets bit by their own bugs, now that's good karma.
Re:The Irony (Score:3, Interesting)
Big Surprise? (Score:4, Insightful)
I'm glad to say that my servers were unaffected. Slapper does not affect AS/400 nor Linux.
Re:Big Surprise? (Score:5, Insightful)
This problem is actually a very interesting one that I've been looking at for years. It happens in everything from 300-person companies to giant mega-corps. It's not because people are stupid, but because large systems only can only avoid tripping on themselves by imposing arbitrary controls.
I think that the right solution is staged anarchy, which is sort of what many large companies (e.g. Microsoft, AT&T, IBM, etc) do with their research divisions or via acquisitions or both. The idea is that you let smart people go nuts and create the unsupportable. You then get more, but different smart people to turn THAT into the supportable. You then get more average corportate drones to convert the supportable into the existing production framework. You then present the existing production framework to the first group of smart people and let them start over again.
You get about a 6-month cycle if you do it right, and you keep reaping the benefits of wild-eyed hacking as well as stability.
Microsoft takes a lot of flack for their technology, but they do this one thing well. You may not like such things as NT, C#, etc, but they are fairly large and complex beasts that most companies would not be capable of cranking out on their own (hence the benefits of open source development so that they don't have to). MS was able to draw on (and some would say corrupt) the smart work of their research folks and of technologies that they acquired and "MS all over it" until it fit their sales and support model, which is one of the reasons that they could do something like go from "Internet-illiterate" to winning the browser war, practically overnight.
IBM does this quite a lot as well (all of their hard drive advances come from this sort of process).
Interesting stuff.
Re:Big Surprise? (Score:3, Informative)
From about Internet Explorer: "Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign." Microsofts "smart work" was assimilating open-sourced non-GPL code to become internet literate. Explains why they dislike the GPL. It puts a damper on their research and innovation.
Re:Big Surprise? (Score:3, Insightful)
Re:Big Surprise? (Score:3, Insightful)
No, it puts a damper on their ability to exploit the freely-offered code and sell it back to people.
You can innovate on GPL'ed code, you just can't keep your innovations to yourself.
Jay (=
Re:Big Surprise? (Score:3, Interesting)
Anyway, I think most people who work with MS patches know they are a trade off between patching the latest holes and breaking something/everything. The only way you can ensure a fully functional application running on an MS OS/DB/web/ActiveX etc. is to baseline the production environment after the application is released. For their activation interface, that would mean not wanting to take the risk of patching once the product is released. That's the price of uptime. Hope they get it now. I bet the admins weren't allowed to patch.
Re:Big Surprise? (Score:3, Insightful)
Re:Big Surprise? (Score:5, Interesting)
Well, the article says that the affected systems were mostly individuals' workstations running SQL server (presumably developers running SQL to simulate a production environment). So these weren't production servers that were affected. Once Slammer got onto the network via the workstations, junk traffic just overwhelmed the routers.
I can't imagine the system/network admins having so much control over developers workstations that they would be responsible for applying patches to SQL servers on those systems as well, especially at a monster software company where just about everyone probably has mini-production test environments right on their workstations. It seems like developers should be responsible for those themselves.
Of course, you have to ask how the thing got in the door in the first place. SOMEBODY that was running an unpatched SQL server must have had port 1434 open to the internet, right? And that WOULD be the admins' responsibility.
Belloc
Re:Big Surprise? (Score:5, Interesting)
It should be blocked at the firewall, but it's possible that the suits ordered the port open so they could access corporate data on the road, and didn't want to learn any of the secure ways to do it. And this exposed developer machines, which aren't as rigourously configured.
Re:Big Surprise? (Score:5, Interesting)
I've got 3 flavours of O/S, and they all need patches. I have a scheduled time to update all O/S's on all servers, then (if needed) schedule reboots. O/S 400 and Linux included.
Surprising how many people flaunt the MCSE on their resume, but have never heard of Mozilla or BEoS or AIX or Slashdot. Those kind of guys I never give a second interview to.
not a bigot. (Score:3, Insightful)
10 bucks... (Score:5, Funny)
Re:10 bucks... (Score:5, Funny)
Are you new to computers?
Re:10 bucks... (Score:4, Funny)
No, no, you don't understand
--Azaroth
patch? (Score:3, Funny)
Just goes to show that no matter who you are, you shouldn't use MS SQL.
but hey, to each their own...
Speaks volumes for their policies... (Score:5, Insightful)
Re:Speaks volumes for their policies... (Score:5, Interesting)
I don't think so. I watched a 4 min report on the Slammer Worm in CNN on saturday and they fail to mention either MS or SQL Server. It was an "internet worm", originated by some haker in the internet for the internet. For 4 min they danced around the news without any mention of Redmond or any of their products.
Re:Speaks volumes for their policies... (Score:3, Informative)
Yep. The same can be said for clicking on virus laden emails. Back when the "I love you" email virus was making the rounds, some MSCE type sent out an email scolding people for clicking on bad emails at the comapny where my wife worked. The next day, her inbox had 50 some emails from him where he'd clicked on a bad email.
Later the same week, our IT dept deployed the last anti-virus patch. I set it off looking at comments on Slashdot where somebody had posted the Word Basic macro that was doing all the dirty work. The dern virus scanner was keying off the macro source. That caused a bru-ha-ha.
Somewhere, deep down in the bowels of Redwood City (Score:5, Funny)
MS Tech guy (Score:5, Funny)
"MSN was total messed up, I couldn't even log on to the net last night it said that my user name and passworded was invalid so I call them up and the tech guy says wow that's weird I can't ether."
Re:MS Tech guy (Score:5, Funny)
It was a really good network.
Microsoft didn't patch all their INTERNAL servers (Score:5, Informative)
Let's not jump too quickly on the bash microsoft bandwagon for that. (Of course, if they just did enough testing and didn't release buggy, vulnerable software in the first place...)
Re:Microsoft didn't patch all their INTERNAL serve (Score:5, Interesting)
Was the Slapper worm developed by a disgruntled Microsoft employee, and unleashed from within Microsoft?
Re:Microsoft didn't patch all their INTERNAL serve (Score:3, Insightful)
Just goes to show that people who are paid to be technically apt can be just as much of a crutch and regular users.
Re:Microsoft didn't patch all their INTERNAL serve (Score:4, Funny)
Re:Microsoft didn't patch all their INTERNAL serve (Score:5, Insightful)
I've worked in some of the Microsoft data centers and done design work... I know how hard they (just like many of my other non-microsoft customer) try to keep people "out" of these networks. But I've seen development projects go on the "soft" network and then get forgotten about. Its machines like these that probably provided the bridge back into MS.
It happens. Regardless of the company. Just some get more publicity than others. You think BofA didn't have firewalls? And yet they went offline for what... half a day or more?
in other news... (Score:5, Funny)
Microsoft on the ball? (Score:5, Insightful)
I fully expect to see more entertaining stories like this for a long time to come.
Re:Microsoft on the ball? (Score:4, Insightful)
Not nessecarly bad administrators (Score:5, Insightful)
Tired of patching? (Score:5, Insightful)
Oh joy, the pleasures of having an automated "Patch-me-now" daemon.
Lazy admin, none the less.
I wonder how long... (Score:5, Interesting)
This, like most other large-scale worm or virus infections, was completely preventable. So many machines are infected due to 1) lazy admins, 2) admins who are asked to do too much and didn't have time to patch all systems regularly (possibly because of staff cuts), and 3) Complete idiots who don't know any better and shouldn't have their job in the first place.
This particular worm largely ignored home and personal computers, due to the product it infects. However, I think a lot of companies sit back and say, "Well, I sure am glad that we have Tom to get this all fixed for us... without him, what would we do?"
That is the problem. Those in charge need to understand that it is both Microsoft's and the admins fault for things like this to occur. It rarely "just happens" and most large-scale attacks were preventable by a month, or even a year before the vulnerarability was exploited.
Eventually, I hope this leads to a shakeout of all the poor admins, or the managers who place too much workload on their admins so that they do not have time to do it right.
Re:I wonder how long... (Score:5, Informative)
Nailed us. (Score:5, Interesting)
It got nailed and then apparently had privileges to come in and nail the rest...
Took us out for 12 hours. We are talking significant production loss here. I'm just thanking
my luck stars that I have nothing to do with our NT setup.
I snicker and do my little dance quietly in my cube.
The Future of Security (Score:5, Insightful)
First and foremost is secure code. Right now, almost everyone and their grandmother has a firewall. They do a good job of protecting ports a user can't shutdown totally (some NetBIOS ports) and protecting insecure applications a user or organization wants to run internally but doesn't want the world to access (NFS, NIS, etc). The majority of these exploits target applications that firewalls will usually let past such as HTTP, FTP and e-mail.
Frankly I'm not sure how coders should go about writing secure applications, but it needs to be done. Perhaps at large organizations there should be a dedicated person or term in charge of verifying code is clear of buffer overflows and other nasties. Either way, the code itself needs to be secure or because a firewall won't do a thing. Without it even the most secure configurations will continue to be cracked.
Second is firewall configuration. Many firewall administrators tend to forget about outbund packets. Obviously there are some they need to let out (HTTP, FTP) but when it comes to things like SQL and outbound portmap, there's really no reason. Depending on the organizations needs they can more than likely block all outgoing UDP. By doing this they can help slow the spread of worms (such as this one) and reduce liability when it comes to crackers using their systems as a point to attack other systems.
Firewalls that block incoming packets just don't cut it, and never have. We need to have secure code and need to block unnecessary outbound packets as well.
hmmm...security + patch administration (Score:5, Insightful)
Yep.
I love the way the article makes security + patching seem such a burden on system administrators. It's one of the main functions of a sysadmin's job. Any sysadmin who thinks security patches are optional, regardless of how shitty your OS's package management + patch integration is, deserves to have their network taken down and their ass fired.
Though I do get a kick out of thinking of the nightmare the Windows admins have keeping up to date with patches, whereas a few hundred lines of perl, and I have my own automated patching system, and RPM keeps track of it ( no rpm vs. deb flames, thank you ).
Re:hmmm...security + patch administration (Score:3, Informative)
As to why I don't use up2date, it's because it chews up to much bandwidth ( ea. workstation hits redhat patch server ). I looked at using Ximian's stuff, but management shot it down.
And if administering w2k boxes is so damn easy, how come very few admins do it right? Proportionally quite a good deal less than their Unix counterparts? I can't verify the comments you made about w2k package management, as I quit doing windows around NT4.0/98 days, but I'll take your word on it. BTW, can this be remotely automated? But, still, how come everyone whines about how hard it is? And how come a frequent complaint ( and one I've seen w/ my site's sExchange mail servers ) is that one patch/update breaks other services/functionality?
Reports are coming in... (Score:5, Funny)
What a bunch of horse shit... (Score:5, Insightful)
Now here's my gripe... Microsoft's being vulnerable to this is only an indication of some lazy sysadmins. It doesn't involve anyone else.
These are typical 14 year old essay arguments, where you can prove the world by altering seemingly unessential facts: while Linux is seen as the OSS giant, and there are thousands of 'independant' people working on it, Microsoft is actually just one person... Bill. Bill has actually cloned himself 40.000 bodies, and attached a wireless receptor in each of their brains, and is brandishing every single one of those people...
Microsoft, just like any other company, is thousands of individual people... this security vulnerability does not undermine the effectiveness of patches.
It's like having a Canada be declared an enemy of the United States because a drunken canadian had a fist fight with some alaskan in some fucking bar. WTF??!?
Come on people, be vigilant.
You and MS are a collective bunch of horse shit (Score:5, Insightful)
Let's make this quick:
MS is a collective. All of the things that individuals do within MS are actions taken by MS. You said it yourself: Microsoft, just like any other company, is thousands of individual people.
MS cannot implement its own patching system coherently. The effectiveness of the MS patch protocol is ZERO as practiced by MS, and I mean ZERO.
This is MS's problem precisely because members of their collective have proven that their system of patches has zero real-world effectiveness.
If you want to apologize for MS, go ahead. Just don't say that they still might be right (about the effectiveness of patching) when they've proven themselves that patching doesn't work, even if because no one bothers to patch.
Worm's damage surprises experts -- takes out ATMs (Score:5, Informative)
~~~
The worm that slowed the internet to a crawl over the weekend apparently did more damage than most originally believed. On Monday, many companies were still struggling to clean up. Financial companies and airlines seemed to be hit most acutely. Many web sites that manage payments and check loans were inaccessible. Inexplicably--and really inexcusably--some ATMS were also unavailable. Investigators are also struggling to pinpoint the worms starting point, but are having little success because it took off so fast.
Apparently similar code was released by David Litchfield of NGS Software Inc a few months ago. Virus "author," "Lion" credited Litchfield's code.
The Washington Post has an AP [washingtonpost.com] story up as well as this [washingtonpost.com], which is older but has some additional details. The kicker to all this--the worm hit one year after Microsoft launched its "Trustworthy Computing." That and even some of Microsoft's own computers were hit [nytimes.com] (NYT Reg. Req.).
(Yep, still bitter
4 Things (Score:5, Insightful)
To clarify some Myths about Slammer (Score:5, Interesting)
Ive read that the patch before this thing went big was a bitch. Basically it was a lot of manual this and that updating and rebooting. Basically this meant a lot of people couldnt get aproval from management to patch the server.
Some have said they applied the patch and still were vunerable.
Some have said the patch fucked their server.
Also, I think I read that the cumulitive SQL server patch that was supposed to be out a long time ago finally came out as soon as this worm hit.
Since I do NOTHING with Sql servers, I dont keep up on this. But I do have to answer to security questions and general FUD so, for those in the know -- whats true and whats not?
Re:To clarify some Myths about Slammer (Score:3, Informative)
I don't understand where the difficulty comes in. You run the service pack, it extracts to your root drive (or whereever you want it to, actually.) You then run setup.bat -- That's it! You're patched!
Some have said they applied the patch and still were vunerable./Some have said the patch fucked their server.
It worked for me, and I can't speak of the ones it didn't work on. SP3 came out a few weeks ago, and admins should have at least had that installed.
Also, I think I read that the cumulitive SQL server patch that was supposed to be out a long time ago finally came out as soon as this worm hit.
Bullshit. The patch to fix the overflow problem came out half a year ago. And the service pack (which includes the patch) came out a few weeks ago.
Don't believe everything you hear..
My Experience (Score:4, Informative)
It's not that bad really, I think later versions of the patch even included a batch file to copy stuff around for you. Even without it, it only took 10 minutes... I mean really, if somebody can't handle this kind of stuff should they really be an admin?
Some have said they applied the patch and still were vunerable.
Yeah you have to be careful with this stuff, if you apply patches in the wrong order you can sometimesend up with the vulnerable code still there. I know a _really_ good admin that got hit with Code Red because of that. The correct order can sometimes be a bit of a mystery.
Some have said the patch fucked their server.
That's the big problem with this situation. I can understand why people don't have this patch or SP3 installed. You really never know what one of these things is going to do. It is common for amins to schedule a 3 hour downtime to roll something like this in, even if they have tested the hell out of it. You need time to get the damn thing back out if it screws stuff up. I deployed W2K SP3 onto my terminal servers a few months ago and it broke Office on every one of them. It didn't do that when I tested it, took me hours to clean it up.
The MS security update is confusing (Score:5, Interesting)
As an aside, the instructions are in a readme.rtf file, even though they are actually just plain unformatted ASCII text pasted into Word. Who in their right minds would have Office 2000 installed on their SQL server? Or is this supposed to be standard practice? Gee, I guess should also look into putting OpenOffice on my Linux firewall.
Here are some quotes from Microsoft's instructions.
OK, but there is also a Microsoft SQL Server\80\Tools\Binn\ directory. What about this one?
ssnetlib.dll "files"? Why plural? I only found one in the path they seem to reference, but actually there was another one in Microsoft SQL Server\80\Tools\Binn\. However there was no ssnetlib.pdb in the main path nor was there even a directory Microsoft SQL Server\80\Tools\Binn\dll.
Again, how can there be ssnetlib.dll "files"? What are they talking about? Also, earlier the (non-existent) ssnetlib.pdb file was supposed to be backed up from the Dll folder, now we put the new one into the Exe folder?
OK, so I unleash Slammer on my network to make sure the problem is fixed? (And how would you test it before Slammer was officially released?)
(NB: some of the above may not be completely accurate, being based on old scribbly notes jotted down in the midst of confusion. However the quotes are direct from readme.rtf.)
Patches break things too… (Score:5, Insightful)
Patches that fix something specific are fine. Patches that add new features or change API behavior can really make a mess. I've seen plenty of kit that requires xx service pack and the latest yy version breaks it.
As a side note, make sure you get the patch if you are running the MSDE on any of your boxes.... Same problem as SQL server - way to many vendors will fold that one into a dev version of a product. I know I almost found out the hard way...
Harping on People To Patch Does Not Work (Score:5, Interesting)
Now Microsoft is in an awkward position. They claim its not their fault: admins should have noticed the original security advisory and patched their machines. But how do they expect 3rd parties to keep up and pay attention when their own internal resources don't?
For a full time system admin that is paid to do nothing but maintain the servers following the advisory and patching escapades is their job. However a developer working on a piece of software that requires MS-SQL Server doesn't have the time nor the energy to. Reading the patch it sounds like it isn't exactly a "click-and-go" process and is a little scary. To a developer I'm not so sure its short sightedness. I spend a lot of time working on product, not following security advisories nor do I spend a lot of time applying complex or risky patches. To a developer the risk of having an unpatched, internal usage machine is much much much less than breaking the environment and screwing up your work schedule.
Harping on admins that got caught is one thing. Harping on developers to follow and apply every patch is futile. So futile that not even Microsoft themselves internally would try.
Problem is IPv4 (Score:5, Interesting)
Trade one problem for another (Score:3, Interesting)
The scary thought for IPv6 to me is that it might slow down random IP propagation, but that would probably be inconsequential when compared with the increased number of spammers that would find new life and longevity in hiding amongst the exponentionally larger IP space.
Re:Problem is IPv4 (Score:4, Informative)
Re:Incorrect (Score:5, Interesting)
Most modern servers are GHz+ boxes, and this worm saturated some 100 MBit links.
My friend, like so many people you simply do not understand large numbers.
Even for billions of computers, the IPv6 address space is so large that it would be extremely sparse. How sparse? Well, let's suppose that you have a 100Mbit link completely filled with 384-byte UDP packets, each with a different, random, address. Let's further suppose that there are 2^32 addresses in use (which is many times what are in use now). From that, we can calculate the average time it would take for slapper on a 100Mbit link to find a single valid address.
100Mbps = 12.5MBps = 32,500 packets per second.
The odds of a random address being valid are 2^128/2^32 = 2^96, so on average, one address will "hit" every 2^96/32500 seconds. A little arithmetic shows that this equates to one hit every 8x10^16 *years*. A slow-moving worm, indeed.
Someone will point out that this calculation is not really fair, because those 2^128 addresses aren't going to be uniformly distributed, and worm writers would know that some of them are impossible. However, the way in which they're going to be distributed won't necessarily make them easy to guess. For example, the bottom 48 bits of your IPv6 address may end up being your hardware MAC address, or a self-chosen random value. Let's be nice and suppose that the worm writer can accurately guess 48 bits. This means that on average an address will hit once every 274 years. Still not likely to be a threat. To make the worm effective, we *also* need to give it a 1Tbit link, which would allow it to find a new host every 13 seconds, on average.
By way of comparison, a slapper saturating a 1Tbit link could blanket the *entire* IPv4 address space in 13 seconds. IOW, a single machine with that kind of a network connection (and the ability to fill it) could find and infect every Internet-accessible IPv4 host more or less instantly.
Nope, I think it's safe to say that with IPv6 worms will no longer be able to make random guesses. That's not to say that there won't be other ways for them to get "good" addresses to probe, but it'll have to be a lot better than random guessing.
Title is incorrect. (Score:5, Funny)
I'm saying that from behind Microsoft's firewall - I should know.
It sure was a giggle on Monday seeing all the warning letters taped on every door and elevator in the building.
Most ops stuff seems up now - as up as they ever are
Oh well... I can still browse slashdot.
I figure this post is blatant karma whoring, but if it helps some geek out there smile...
**Microsoft Confidential - Do not forward**
All Computers Running SQL Server 2000 and
MSDE Required to Load SQL Server 2000 Service Pack 3
say no more!
Zero defects impossible; fix the fences instead (Score:5, Informative)
Zero defects is not an attainable goal; it's too expensive and no one wants to pay for it.
This article shows just what happens when you expect zero defects in the infrastructure of a large organization like Microsoft Corporation. It's not going to happen. And before someone says I'm Microsoft-bashing, I will say that this is true for the vast majority of corporations, universities, foundations, and governments. That would include Sun, IBM, Red Hat, even the *BSD folks and LKML participants.
There is a damn good reason we won't see zero defects: employees are not measured by it. Their survival, pay raises, and promotions are based not on the number of defects they don't have, but on their contribution to the "bottom line." If you preach zero defects as Job One, then prove it by firing the people who generate defects, without exception -- including the CEO, COO, CFO, CIO, and other top brass, when they screw up.
So now that the myth of zero defects has been exposed for what it is, what do we do about it?
System administrators are going to have to re-think their perimeter access controls. This may require router upgrades to add processing power to support additional filtering.
Sysadmins who have been running "mostly-open" filter configurations may want to consider moving to a "mostly-closed" configuration: deny everything except services that have been cleared for use. Don't allow arbitrary connections. Many unknowing MS SQL servers were protected from participating in this little exercise because the firewall upstream of the desktop system wasn't allowing connections to get through, even if the desktop system had a globally-routed Internet address.
Computer mail order houses and computer stores should consider carefully whether they should bundle appropriate software firewall products with the computers they sell. Software configured to require the user to say "Yes, I want to make SQL server available for public access!" before 1433 and 1434 would be open.
We need to ask the reporters and editors of mainstream publications to be more responsible when reporting problems like Sapphire/SQL. The facts were pretty well known, and available to those who tried hard enough to get them even at the height of the packet storm, so that reporters could make their deadlines and get the facts straight. [Names of the guilty withheld, at least for now -- they know who they are.]
Tier 1 and Tier 2 bandwidth providers need to consider modifications to their Acceptable Use Policies to require some basic filtering of packets in both directions. These AUP changes have been discussed before; perhaps now is the time for them to go into effect:
Update the Best Practices RFCs to incorporate some or all of these suggestions, so that Internet operators around the world can participate in solving the problem.
(N.B.: I want to point out that many USA-based cable operators are contributing to the problem by disallowing the use of NAT and VPN technologies in their apparent [alledged] quest to limit the broadband "Internet service product" to browsing and downloading files. I believe that such an attitude contributed to the problem, not the solution. I understand well the technical and business motivations for this, but I also believe that there are (U.S.) national security implications against such a policy. THINK!)
Are any of these ideas new? NO. The only new idea is to have the Lords Of The Internet use their influence over their customers to implement them more widely.
Good fences make good neighbors. The Internet is a neighborhood.
Re:Zero defects impossible; fix the fences instead (Score:5, Interesting)
Oh, boy. Is this ever a religious argument. There are sysadmins out there who are afraid to block any port because of customer backlash when "their" favorite port is blocked. I recall a CCIPP certified network guy who lambasted me for running a mostly-closed configuration at a conference -- he wanted to use SSL on an alternate port, and HATED it when I blocked access to it. (Further details withheld intentionally.)
Then there are people who will not use ISPs who block ports, for whatever reason. "'Internet service' means 'internet service', not 'some internet service.' DON'T BLOCK MY PORTS. If I need protection, I'll buy 'Depends'." And so forth.
That's part of the nature of the marketplace, so don't go blasting the competence of sysadmins who, for business reasons, have to do something they would rather not do. He Who Has The Gold Makes The Rules.
(Damn, that's what I get for running out of coffee this morning.)
TCO (Score:4, Funny)
I just hope this means... (Score:3, Interesting)
That these morons basically brought the internet to its knees Friday night through gross incompetence should be reason enough to fire every last one of 'em.
- A.P.
Useful script for keeping up-to-date with RPMS. (Score:4, Informative)
wget -nd -nH --mirror --no-parent --passive ftp://ftp.mirror.ac.uk./sites/ftp.redhat.com/pub/
wget -nd -nH --mirror --no-parent --passive ftp://ftp.mirror.ac.uk./sites/ftp.redhat.com/pub/
saved=`grep saved log | grep -v ".listing"`
check=`rpm -K
if [ "$saved" ]
then
mail user1@domain.com user2@domain.com <<EOMAIL
New RedHat 8.0 RPMs downloaded onto `hostname`
Please update them:
$saved
$check
If there are any kernel updates, please run lilo before rebooting
EOMAIL
fi
Run this in the night some time.
When you come in, if you've got an email, run:
cd
rpm --freshen -vah *.i686.rpm
rpm --freshen -vah *.i386.rpm
Hey presto. Job done. And if you use Grub, you don't have to bother about running lilo.
Matter of cost . . . (Score:4, Insightful)
It seems to me if one were to include the costs of patching, insuring everything gets patched, and the expected losses (I assume probality is inherently high in then non-Unix world) from the inevitable missed patch (or, nonexistent patch/late patch), MS TCO would go through the roof. Then again, maybe the entire concept of TCO doesn't matter when the most significant costs can be hidden from ignorant managers who act as the software purchasing agents of the company.
The problem is including new features with patches (Score:5, Insightful)
For years I was forced to run an IIS server which was outdated, unpatched, and very vulnerable. I couldn't update it because the service packs would break the software running on it - and the reason was that the service packs, while they fixed the vulnerabilities, also introduced all sorts of new features I did not need or want. So I was reduced to keeping a very watchful eye on it.
The entire infrastructure of Microsoft software distribution method is simply broken, and stupid.
How about a solution? (Score:3, Insightful)
Never patch a running system ;-) (Score:3, Interesting)
It's easy to blame someone for not having his/her systems patched. But i believe, that the average patch level on Windows Systems is higher than on Unix systems.
Most of the Unix (espescially servers) system just run and don't cause trouble. So nobody thinks of and patches them. A 1000+ days uptime is something to make a sysadmin proud and a security adviser weep.
As many Windopws sysadmins have trouble to debug their system in depth, in the case of problems they try to apply available patches first (second action taken after reboot). So, as Windows systems cause more trouble than Unix servers, they are better patched. Q.E.D.
Just kidding, Martin
And the letter from Microsoft (I kid you not) (Score:4, Interesting)
I'm writing to you about an issue of particular importance to those of us who routinely use computers in our work and personal lives - making computing more secure. Before I share my thoughts about this in more detail, I want to give you some context on why I am sending this email.
This is one in an occasional series of emails from Microsoft executives about technology and public-policy issues important to computer users, our industry, and anyone who cares about the future of high technology. If you would like to receive these emails in the future, please go to http://register.microsoft.com/subscription/subscr
******
As we increasingly rely on the Internet to communicate and conduct business, a secure computing platform has never been more important. Along with the vast benefits of increased connectivity, new security risks have emerged on a scale that few in our industry fully anticipated.
As everyone who uses a computer knows, the confidentiality, integrity and availability of data and systems can be compromised in many ways, from hacker attacks to Internet-based worms. These security breaches carry significant costs. Although many companies do not detect or report attacks, the most recent computer crime and security survey performed by the Computer Security Institute and the Federal Bureau of Investigation totaled more than $455 million in quantified financial losses in the United States alone in 2001. Of those surveyed, 74 percent cited their Internet connection as a key point of attack.
As a leader in the computing industry, Microsoft has a responsibility to help its customers address these concerns, so they no longer have to choose between security and usability. This is a long-term effort. As attacks on computer networks become more sophisticated, we must innovate in many areas - such as digital rights management, public key cryptology, multi-site authentication, and enhanced network and PC protection - to enable people to manage their information securely.
A year ago, I challenged Microsoft's 50,000 employees to build a Trustworthy Computing environment for customers so that computing is as reliable as the electricity that powers our homes and businesses today. To meet Microsoft's goal of creating products that combine the best of innovation and predictability, we are focusing on four specific areas: security, privacy, reliability and business integrity. Over the past year, we have made significant progress on all these fronts. In particular, I'd like to report on the advances we've made and the challenges we still face in the security area.
In order to realize the full potential of computers to advance e-commerce, enable new kinds of communication and enhance productivity, security will need to improve dramatically. Based on discussions with customers and our own internal reviews, it was clear that we needed to create a framework that would support the kind of innovation, state-of-the-art processes and cultural shifts necessary to make a fundamental advance in the security of our software products. In the past year we have created new product-design methodologies, coding practices, test procedures, security-incident handling and product-support processes that meet the objectives of this security framework:
SECURE BY DESIGN: In early 2002 we took the unprecedented step of stopping the development work of 8,500 Windows engineers while the company conducted 10 weeks of intensive security training and analyzed the Windows code base. Although engineers receive formal academic training on developing security features, there is very little training available on how to write secure code. Every Windows engineer, plus several thousand engineers in other parts of the company, was given special training covering secure programming, testing techniques and threat modeling. The threat modeling process, rare in the software world, taught program managers, architects and testers to think like attackers. And indeed, fully one-half of all bugs identified during the Windows security push were found during threat analysis.
We have also made important breakthroughs in minimizing the amount of security-related code in products that is vulnerable to attack, and in our ability to test large pieces of code more efficiently. Because testing is both time-consuming and costly, it's important that defects are detected as early as possible in the development cycle. To optimize which tests are run at what points in the design cycle, Microsoft has developed a system that prioritizes the application's given set of tests, based on what changes have been made to the program. The system is able to operate on large programs built from millions of lines of source code, and produce results within a few minutes, when previously it took hours or days.
The scope of our security reviews represents an unprecedented level of effort for software manufacturers, and it's begun to pay off as vulnerabilities are eliminated through offerings like Windows XP Service Pack 1. We also put Visual Studio
Looking ahead, we are working on a new hardware/software architecture for the Windows PC platform (initially codenamed "Palladium"), which will significantly enhance the integrity, privacy and data security of computer systems by eliminating many "weak links." For example, today anyone can look into a graphics card's memory, which is obviously not good if the memory contains a user's banking transactions or other sensitive information. Part of the focus of this initiative is to provide "curtained" memory - pages of memory that are walled off from other applications and even the operating system to prevent surreptitious observation - as well as the ability to provide security along the path from keyboard to monitor. This technology will also attest to the reliability of data, and provide sealed storage, so valuable information can only be accessed by trusted software components.
SECURE BY DEFAULT: In the past, a product feature was typically enabled by default if there was any possibility that a customer might want to use it. Today, we are closely examining when to pre-configure products as "locked down," meaning that the most secure options are the default settings. For example, in the forthcoming Windows Server 2003, services such as Content Indexing Service, Messenger and NetDDE will be turned off by default. In Office XP, macros are turned off by default. VBScript is turned off by default in Office XP SP1. And Internet Explorer frame display is disabled in the "restricted sites" zone, which reduces the opportunity for the frames mechanism in HTML email to be used as an attack vector.
SECURE IN DEPLOYMENT: To help customers deploy and maintain our products securely, we have updated and significantly expanded our security tools in the past year. Consumers and small businesses can stay up to date on security patches by using the automatic update feature of Windows Update. Last year, we introduced Software Update Services (SUS) and the Systems Management Server 2.0 SUS Feature Pack to improve patch management for larger enterprises. We released Microsoft Baseline Security Analyzer, which scans for missing security updates, analyzes configurations for poor or weak security settings, and advises users how to fix the issues found. We have also introduced prescriptive documents for Windows 2000 and Exchange to help ensure that customers can configure and deploy these products more securely. In addition, we are working with a number of major customers to implement smart cards as a way of minimizing the weak link associated with passwords. Microsoft itself now requires smart cards for remote access by employees, and over time we expect that most businesses will go to smart card ID systems.
COMMUNICATIONS: To keep customers better informed about security issues, we made several important changes over the past year. Feedback from customers indicated that our security bulletins, though useful to IT professionals, were too detailed for the typical consumer. Customers also told us they wanted more differentiation on security fixes, so they could quickly decide which ones to prioritize. In response, Microsoft worked with industry professionals to develop a new security bulletin severity rating system, and introduced consumer bulletins. We are also developing an email notification system that will enable customers to subscribe to the particular security bulletins they want.
WHAT'S NEXT
In the past decade, computers and networks have become an integral part of business processes and everyday life. In the Digital Decade we're now embarking on, billions of intelligent devices will be connected to the Internet. This fundamental change will bring great opportunities as well as new, constantly evolving security challenges.
While we've accomplished a lot in the past year, there is still more to do - at Microsoft and across our industry. We invested more than $200 million in 2002 improving Windows security, and significantly more on our security work with other products. In the coming year, we will continue to work with customers, government officials and industry partners to deliver more secure products, and to share our findings and knowledge about security. In the meantime, there are three things customers can do to help: 1) stay up to date on patches, 2) use anti-virus software and keep it up to date with the latest signatures, and 3) use firewalls.
There's much more I'd like to share with you about our security initiatives. If you would like to dig deeper, information and links are available at http://www.microsoft.com/mscorp/execmail/2003/01-
Bill Gates
For information about Microsoft's privacy policies, please go to: http://www.microsoft.com/info/privacy.htm
Patching.... (Score:5, Interesting)
If a major motor manufacturer created a product line that lost the brakes when the temperature outside was -10 degrees and on an interstate, they would be liable.
If 90% of the population used that product line and people were getting hijacked by their own transportion, there would be hell to pay.
Now suppose that they say, "Hey! We released a recall two months ago? Didn't you take your car in to fix it? We made a post to our service centers, but you never saw it at the place you take your car? If you were running our brake-warming device (aka anti-virus software), you wouldn't have had this problem... if you were on a local road instead of an interstate, you never would have had this happen to you. Please buy more of our products. "
I know its outlandish, but there should be some responsibility here on the part of the vendor. There is economic damage from not patching stuff, but if the patch usually breaks your car, who's left to hold the bag?
Unless you are a mechanic and own a kit-car (aka Linux), you're tied in. That's not good.
T.
What's incredible... (Score:4, Insightful)
Single layered security == flawed (Score:4, Insightful)
You have to assume there *are* holes in application software such as SQL server due to its complexity.
Taking a reactive approach, and simply installing hotfixes are they're available will simply not work - patches are often not available until a number of days/weeks/months until after the vulnerability is known. Even if it hasn't been fully disclosed, the blackhats may well know about it, or be prompted to scrutinize that particular product more and find it before the full announcement.
The correct way to deploy such products is to design your network with this in mind, and firewall them off from the rest of the world.
That does NOT give you the security to not worry about patching (single layer security is bad) - keep your servers patched - but it does buy you a little time, and is an extra layer of defense in case there is a server that doesn't patch properly for some reason (file couldn't be overwritten for example), or is accidentally forgotten about.
I can think of *no reason* why an SQL server must be accessible to the world. You have a webserver that uses it as a back-end? Give the public access to port 80/443 of that ONLY, and disallow connections from anywhere but localhost to the SQL software. Even better (and the approach I always take - I don't trust Win-X to be visible to the internet, period), install it on a seperate physical machine, firewall that machine more tightly (ie, allow SQL connections ONLY from machines that require them, such as your webserver).
If you have client machines that need to access the database from the internet, thats what VPNs are for.
Since I've had enough sense to firewall my servers correctly (yes, I was a clueless idiot before as well ;), I have not had a single security breach.
I'm not saying that I'm definately immune to a concentrated attack, but you can definately stack the odds in your favour.
Yes, it is an investment in time, and probably money - but if you want a secure network, its simply the price you have to pay these days... how much is your data/uptime worth?
smash.
Re:Possibly??? (Score:5, Funny)
i would've beat you if MS SQL wasn't slowing me down
Re:Say what? (Score:5, Insightful)
They probably don't. What's more likely is that one or more employees took their laptops home and hooked them up to their own Internet connection without any personal firewalling active. If those laptops happened to be running SQL Server, they become carriers. All it takes then is for them to be plugged back into Microsoft's LAN, and game over.
Re:Say what? (Score:4, Informative)
Of course - it only takes one infected client
Re:Say what? (Score:3, Informative)
Re:Say what? (Score:3, Informative)
Go home, plug into cable/DSL. Get infected. VPN in to Microsoft. Ooops.
Re:Despite what the apologists say (Score:3, Interesting)
It turns out that you now have to register for a Passport account in order to recieve their security alerts. They simply changed this and didn't notify anyone who stopped receiving alerts. Oh, I'm sure they put a message up somewhere, but...
I refuse to get a Passport account, so I still don't get them, but I guess I can only blame my stubbornness for that.
Re:Despite what the apologists say (Score:3, Informative)
I usually just go here rather than searching endless volumes....
http://www.microsoft.com/technet/treeview/default
Re:Despite what the apologists say (Score:5, Insightful)
Another clueless jackass spouting off about things he has no idea about...
flawless! (Score:3, Funny)
Rick Devenuti, the chief information officer for the software giant... "We are not sure how the virus got into our network," Must have been terrorists! ... "It just takes one machine to get going," he said. "At any given point in time, it is hard to be 100 percent patched with any machine. We are working hard to make patch management easier. But 100 percent is a high bar and in this case we are not there."
Oh, it's too hard, that's it. Too bad they don't have a nice system like Debian's stable distro and apt-get upgrade to keep things all patched up. But wait, M$ patches break other software! It must just be impossible to keep them up.
I'm so sorry that I called those poor M$ admins losers. Blaming the user for your shitty software's failures is a Microsoft thing to do.
Re:M$ Winblows Update (Score:3, Funny)
Pfft.
Re:Reboot Boys Alert (Score:5, Funny)
So... by announcing which ones have been running that long, they are announcing which ones are vulnerable to known attacks.
I guess they won't be on the list for long.... :)
frob