Slashdot Mirror
Slammer Worm Slams Microsofts Own
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."
At my office, we weren't vunerable because we /didn't/ upgrade. We were still running SQL 7.. Just goes to show you...
Oh the irony in this. Microsoft always insists you update your patches, but for some reason they don't. O well this could be a good thing for network administrators as at the end it stated they were going to work on a new way to install patches.. Or thats what it looked like they said to me.
It kind of makes you wish someone gets fired over this. Not just forgetting to patch the servers at MS, but all of the servers that choked the internet to a crawl. But I wouldn't wish that on anyone right now. Talk about a tough job market.
I wonder how long it will be before companies that are hit hard by this will start terminating those responsible. Now, obviously part of the blame goes to the one responsible for the infected machine, and part of the blame goes to the software maker (Microsoft in this instance).
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.
If you had nuts on your chin, would they be chin nuts?
God knows why, but our company had an NT box running MS-SQL outside the Unix firewall.
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.
Was the Slapper worm developed by a disgruntled Microsoft employee, and unleashed from within Microsoft?
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.
"History doesn't repeat itself, but it does rhyme." Mark Twain
if this info gets around enough
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.
They do have a security alert service that you can sign up for. I USED TO belong to it, but then one day I suddenly stopped recieving them (with NO notification or explanation).
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.
I doubt its going to do anything. Code Red is still running around inside of the network. Not that bad anymore however last summer, you could set up a "clean" machine and if you plugged it into the network, it would take about 15 minutes to get infected.
Too many developers setting up machines without understanding what they were doing or without an admins help. Just keeps the bugs going practically forever... And code red has been out for a LONG time...
Ive been hearing a lot of this and thats and I was hoping to get the straight dope.
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?
The ultimate network admin tool needs HELP!
Well..sort of. SQL Server 2000 SP3, which fixes this problem, comes in a self-extracting exe which asks you for the target directory. You then go to that target directory and run setup.bat: The installer automatically shuts down SQL Server for the initial part, installs the patches (you copy over absolutely no dlls or binaries), restarts SQL Server for the final part where it then runs the update SQL scripts. It really is a trivial process. As far as backing up your data you should be doing that regularly anyways. This process is the same for MSDE installations.
I don't know where this myth of hyper-complex SQL Server updates came from. Admittingly it is a bit more complex if you have multiple instances, but generally that goes along with more advanced administrators anyways.
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.)
Well this episode shows that you can drag the camel to the well but you can't make them drink the water.
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.
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.
No one's laid blame on it, but I think that the real way to get rid of these worms is to transition the net to IPv6. Slammer, Code Red, Code Red 2... all of them work by brute-force IP scanning. That only works because the IPv4 addres space is so densely populated; with IPv6, a worm would never be able to spread itself that way because the odds against a random hit are astronomical. I'm not saying that this should be a substitute for keeping servers up to date, but all the patching in the world doesn't help when the problem is that some faraway node is crushed under the traffic created by a worm, and IPv6 is good for many other reasons as well.
If the parent wasn't modded insightful, I'd call it a troll :)
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.
http://pcblues.com - Digits and Wood
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."
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
...a lot of unemployed second-rate MS SQL admins should be hitting monster.com soon, if management have any sense whatsoever.
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.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Why does it suprise anyone that Microsoft has bad admins, the same as anyone else.
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
I got more rhymes than Jamaica got Mangoes.
I would verify but the hotfix in question has an auto-extraing exe that as a part of the extraction process first checks if there is a compatible instance of SQL Server. There isn't even a readme with this file I noticed, and my presumption is that the exe automatically installs the hotfix (given that it has the brains to check that there is a compatible version as a first step), though I can't verify that as my instance is already SP3. I'm not saying you're wrong, but I am curious how the hotfix experience is for anyone else who grabbed that file.
You are right.
Another similar scenario would be that someone get infected at home and connect to the MS network via VPN (I'm assuming that MS offer that to a certain number of employee), that way the worm will still be resident and may infect the MS network.
Would you rather have a system where you have to manually implement every patch, or would you rather have a system where you didn't have any choices which patches were implemented?
.NET and WMP 9 on your computer. The second choice would also automatically sign you on to whatever contrac--er...license agreements that came with the patches.
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.
What's this Submit thingy do?
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
it really does show that their policy of blaming the users for not patching their systems perhaps isn't the best approach to take.
Recently we had a server crash, and unfortunately it was handling some of our legacy compatibility services. When it went down it, it was amazing how many little things we had always meant to kill off, but couldn't or didn't. Why not? Becuase it was simply safer to keep it running then clean house at that time.
Now we're forced to move on, and shake off the old shackles. It feels good, but I don't like doing it. Every upgrade is a potential break, and its worse that they come at such random intervals.
Its ironic that the "safety" reflex that simultaneously attracts one to Microsoft will make them vulnerable to these kinds of exploits. I admit I feel that safety reflex everytime I have to patch a legacy app, I don't blame the MCSE's for resisting these small patches.
So in essence, I agree. They are victims of their own sense of security. I am a victim of my own sense of security. You know when Thomas Jefferson said a revolution in government every some-odd number of years is a good thing, I wish I could do the same for my network rather then deal with the incremental cruft. But then with a million other sys-admins on this board, I'd cringe doing that too.
I guess theres just no easy answer. It won't work perfectly out of the box, and any change will bring potential problems. Its the duplicity that keeps me employed, yet wrings my guts sometimes.
_____________________________________
OnRoad: Reporting the SUV war from the middle of the road.
Jan. 23, 2003
i beMe.asp?lcid=1033&id=155 to subscribe. If you don't wish to hear from us again, you need not do anything. We will not send you another executive email unless you choose to subscribe at the link above.
.NET through an incredibly vigorous design review, threat modeling and security push, and in the coming months we will be releasing other major products that have gone through our Trustworthy Computing security review cycle: Windows Server 2003, the next versions of SQL and Exchange Servers, and Office 11.
2 3security2.asp to help you make your computer systems more secure.
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
Why was this port open to the internet in the first place? Shouldn't the database servers be behind the firewalls, and only accept connections from trusted hosts on the outside? the rapid spread of this worm seems to point so serious design problems with the networks at many companys. The Bank of America infection is particularly troubling.
This is precisely why the development groups need to be sequestered into a heavily firewalled ghetto. Having worked on both sides of the fence I'm appalled at the carelessness with which many supposedly professional software developers build their work environments. Unfortunately the cardinal virtue of laziness is often interpreted as sloth.
In the admins defense, there are rarely enough hours in the day to get everything done, especially if one set of tasks (patching MS SQL Server) is time consuming and prone to error. I assigned one MCSE the task of keeping the Windows servers patched as his primary priority and I swear he was busier than a one legged man in an ass kicking contest. Between the OS, the web servers and SQL he never finished before the next patch/hotfix/service pack was released.
Sure it's easy to say that they're bad admins and just lazy but the reality is that the work load often pushes some tasks to a point in the queue where they will never see the light of day again.
-jaded- walking the earth as a living corpse is in somewhat questionable taste
This is really scary:
"On Saturday, the Microsoft's Windows XP Activation service was down, not because the servers were vulnerable, but because the company's internal network was inundated with junk data, Rick Devenuti, the chief information officer for the software giant, said in an interview Monday."
Microsoft told us that the Activation service would ALWAYS be available. I would have been PISSED if I had to reactivate my XP on Saturday and wasn't able and then wasn't able to use my PC!
I disagree about the difficulty in propagating the worm under IPv6. It might slow it down, but I was online when the worm hit and it was almost instant the way it consumed the backbones. I'd estimate that within 5-10 minutes the worm went from one end of the world to the other.
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.
Let's take it to a new level...
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.
This space for rent.
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.)
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.
One line blog. I hear that they're called Twitters now.
What staggered me about the whole episode is that there are people running SQL Server open on the internet. Why? Something as large and as complex as an RDBMS product is a inviting disaster (applies as much to Oracle etc. as SQL Server as well). All my databases are buried well behind firewalls that don't allow any access from the internet. Use a VPN if you need to access databases over the internet. There are free ones available...
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.