Slashdot Mirror
When Will The Next Slammer Strike?
scubacuda writes "Business Week has an article on how the Slammer worm demonstrates just 'how vulnerable the Internet remains': MS's own DBs were affected, telephone/ATM/etc were knocked out, and if the worm had occurred only 48 hours later (preventing investor's trading, 911 calls, banking services), there could have been a 'virtual Net shutdown.' Vincent Weafer, director of the computer-security outfit Symantec's Anti-Virus Response Center (SARC), says that the likelihood that a Slammer-style worm will hit at a more vulnerable moment is high."
In my opinion, there are two ways that people will react to the problem of exploits in computer software:
In the short term, I expect that the most recent attack will provide a huge sales boost to pre-packaged "security solutions" like firewalls, virus protection, etc. and will probably be used as an extra card that the government can play when arguing for implementing a comprehensive Internet monitoring system. Of course, both of these things are unfortunate, as neither one promotes security and the latter gives the government way too much power . . .
Long term, the best protection against exploits in computer software is a shift in attitude about where software companies should place their priorities. At present, it is more lucrative for companies to push a piece of software out the door and sell upgrades than to spend extra time developing secure software. Only a strong fiscal mandate from corporate customers will change the way software companies do business . . . and I hope that mandate comes soon.
MS products are too buggy for the internet. Even when MS comes out with patches sysadmins are extremely reluctant to apply them (even at Microsoft) in fear that the patch will cause more problems (ie BSOD) than it fixes. Remember Microsoft got hit by Slammer hard because it didn't install its own patches. Was Microsoft waiting for customers to beta test thier software before they even tried it themselves??? Plus the MS SQL server is not the only MS product that Slammer can infect......when are people going to hold Microsoft accountable for its lack of security and general poor coding??
"You helped our nation celebrate its bicentennial in 17 -- 1976." --George W. Bush, to Queen Elizabeth, Wash
It is unclear in the article if they mean ATM as in bank ATM's, or ATM as in asynchronous transfer mode networks. I'm sure the author doesn't even know in which context ATM is used.
Just a thought *shrugs*
The same MS that didn't apply their *own* patches ?!?
The problem that I have is, even though I don't run any Microsoft software, their incompetence keeps on screwing me around and costing me productivity.
I get hundreds of e-mail virii per day, owning partially to incompetent users, but also partially to incompetent Outlook programmers.
At the height of Code Red, I was getting hundreds of hits per day to my webserver.
That last worm effectively shut down portions of the Internet.
Now, here's the problem. If I'm driving down the road, and a Hyundai's brakes fail and cause it to run a red light and plow into the side of me, it'll piss me off, but it's a quirk, and shit happens.
If, every couple of months, a Hyundai's brakes fail and I get hit, pretty soon, I'll start to get very pissed off, not just with the idiots who drive Hyundais, but also with Hyundai itself.
This has gotten to be utterly ridiculous. We have to find some way of holding Microsoft accountable for their fucking ineptitude.
Fire and Meat. Yummy.
My assumption was that they were talking about ATM (Asynchronous Transfer Mode). Many ATM networks were significantly hurt by this because routers and switches that utilize SVCs kept building and rebuilding circuits.
The whole point of this problem can be simplified to bad code and bad base installs. I keep hearing people say it's not MS's problem. I work with a wide variety of products in the networking (L2 & L3+ WAN) and systems world. Any one of the vendors that I deal with would lose serious market share if their products were found to be vunerable to something like this and they simply patched it but didn't change the base install to be "secure".
Let's start by taking an example of a comparable product -- postgreSQL. We all know that a recent patch to this product fixed a possible remote exploit. Certainly the bug shouldn't have been there and it was something that should be patched. However, the point is that the postgreSQL base install doesn't even allow remote connections. In fact, the config file tells you that without remote connections allowed, it's still probably an liberal configuration that should be locked down more.
I'll buy that MS has a large market share and that occasionally something will get through the normal protections; however, the base installs should be locked down. Why aren't they? It's a question that is very simple to answer.
MS sold the Internet community a grand story. In this story, running a server is a simple task that anyone can do. For this story to be believed, they have to have the base install do everything out of the box without any special configuration which might require a real administrator, dba, network design specialist, etc. If the products were actually locked down like they should be (like most of the competing products are), MS would have a bigger job in support calls because 80% of the non-administrators that work with MS platforms would be ill-equiped to handle the proper configuration of the server to get it to work.
I have a product that I use on linux that was written with this kind of security in mind. The config file is riddled with lines like: die "you didn't go through your config file!". If you don't completely configure the product, it keeps dying on startup. This is how products should be released--locked down and set to die if the configuration is not explicitly setup by the admin with them being aware of the dangers to each option they set back on.
I also hear a lot of people complaining that people didn't install the patches, I again go to the point of the base install. If the product's base install were locked down, far less databases would have been open even if they were unpatched. Seriously, let's be reasonable, why should an SQL server open ports by default to anything except maybe 127.0.0.1. Many databases now only need one or two subnets open anyway since their database interaction goes on with an application server (often a web server) which serves as the db client for the users anyway and quite a few databases on the lower end systems (where most of the sysadmins who don't know how to lock things down are) reside on the same box as the app services.