Slashdot Mirror
Microsoft Blasted For Lax Security
fducky writes "Once again Microsoft is blasted for lax security. This CNN article cites experts denouncing the recent Microsoft security efforts as rating an 'F'. The recent MS-SQL worm got this most recent round of MS bashing going. Google News has more stories on the subject."
doh! from the CNN article: "The single largest message is: keep your system up to date with patches," Microsoft Chief Security Officer Scott Charney said. But the philosophy of patching is fundamentally flawed and leaves people vulnerable, Cooper said. For example, Microsoft didn't follow its own advice as executives confirmed that an internal network was hit by the worm.
I am always running behind on M$ patches for 2 reasions:
#1. MS patches have "blown up" my win boxes before.
#2. There are so many you can't keep up.
And automatic update that comes with Windows 2000 SP3 has also hosed my PC.
Karma: The shiznight, mostly because I am the Drizzle.
The related article is here:
Survey Reveals Geographic Illiteracy
Worst than this, lets suppose that you want to be patched at any cost, as soon at it appears. Another patch coming from microsoft for another MS SQL problem disabled this patch (this is in the CNN article linked in this story), so you must be half responsible, half not, to have one patch applied and not the later one, to be safe.
Personally I'm not blaming Microsoft for the 'slammer'. They patched it in July so I'm blaming the morons that
1. Haven't bothered to keep their SQL servers up to date
and
2. Allow anyone from the internet to connect to that port anyway!
Auntie Gayle's Basic Firewalling Guide for fuckwits
1. Drop EVERYTHING!
2. Specifically open the ports you need.
3. If you do this the other way round (i.e. only drop known problem ports/protocols while leaving everything else open) please report for immediate recycling.
The one thing Microsoft are responsible is for making the sysadmin job seem so easy any moron can do it. This encourages companies to employ button pushers and we end up with things like the 'slammer' debacle.
but ... what if this patch breaks your important system???? what is common for ms patchs....
then you get f*** for taking down a working system and you can never prove you had done something necessary
if you can't trust the patches you have to wait 'till you have feedback from other users
that means to have to check for every patch in combination to every applications you use
at many points it is even easier to "drop the ball" and reinstall after something happened
stop supporting microsoft with pirating their software!!!!!
The bit that gets missed here is that security is not a product, its a process (something Bruce only seems to remember when writing his books). If we really want to go pointing fingers than how about the folk who designed buffer overflow bugs into the C programming language? Before C every programming language had array bounds checking built in. So who were the turkeys who decided that we should run without elimentary safety checking? Oh yes the same folk who gave us what people would now have us believe is the so-secure UNIX O/S.
It took over ten years for the elimentary security boo-boos to get sorted in UNIX. For years the UNIX crew told us that shadow passwords were dangerous security through obscurity, only the world readable password file and the salt gave genuine security. Then along came crack. It still took four years for shadow passwords to become mainstream.
Even today sendmail is installed by default in most UNIX installations, even though it is historically a security nightmare. Some of the bugs have been fixed but as a sendmail inc. employee admitted to me last week, it is still too dammn complicated for most people to understand how to configure it.
I don't think that this point scoring does any good. UNIX and Windows both have major security problems. Windows has security problems in implementation, UNIX has them built into the architecture. There are still UNIX boxes shipping with rhosts, even though it has been demoinstrated time and again that rhosts is completely insecure. Instaling ssh does nothing to improve the security of the box unless you actually uninstall the rhost commands and the daemon.
Folk who go on about how braindamaged Microsoft is should ask themselves how UNIX programmers managed to botch a command as simple as finger!
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
According to the CNN article: In October Microsoft released a fix for a different SQL Server problem that if installed in the expected manner would have made patched systems vulnerable again, he said. "If I followed their advice I'd have been vulnerable."
As a server admin, how do you know which patches will cause more harm than good? Is a good server admin one who installs every patch that's released right away and breaks things, or one who doesn't and gets broken into? When we installed SQL Server's SP3 at work, we found that the statement "DBCC SHRINKDB('insertDatabaseNameHere')" was depricated and disabled in favor of using "DBCC SHRINKDATABASE('insertDatabaseNameHere')". This wasn't a new release... this was a service pack! I don't think you can solely blame admins for not patching. Some blame HAS to fall on the coders who left the hole open in the first place.
Heh, did you read the article? No, you didn't.
A recent patch sent out in October actually made the servers vulnerable again. So if you patched with the old patch, and then the one in October, you were screwed.
I can't. But Bruce Schneier can
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Good question, why did several of the root DNS servers go down? If I remember right, they run BIND.
My guess: Flooding from infected personal boxes caused a DoS on the SQL servers and routers resulting in some service used by Windows Update to be unavailable. It is also possible that the people maintaining those servers didn't do their job, but there are other possible explanations.
Actually you are both right. Although Service Packs often roll up hot-fixes, they also can include many more bug fixes that weren't deemed important enough to require releasing as a hot-fix. Thus they are much more likely to include a deliberate incompatible change that breaks an application (i.e. DirectX N+1, or the above-mentioned DBCC behaviour).
However, although hot-fixes are usually small changes targetted to fix a particular problem, they do not undergo the full regression testing that a service pack does. Most MS hot-fixes come with an CYA warning that you shouldn't apply it unless you believe you are in a situation exhibiting the problem and requiring the hot-fix. Since code modularization at Microsoft seems to be dictated at least as much by the marketing and legal departments as by good software engineering practice, a hot-fix has a not-insignificant chance of having an unexpected side effect (witness the problem with the October hot-fix).
So whether it's a hot-fix or a Service Pack, you wind up having to regression test your 3rd-party applications before deployment, and if you think most IT departments can afford to do that with every "hot-fix of the week" you're out to lunch. Most admins would probably have deployed SP3 after performing their own regression tests in another few weeks.
That said, what kind of idiots connect 120,000 unprotected database servers out on the net? I doubt all were in the position of the poor slob a few levels above in this thread who had deployment mandated by upper management.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
OK: Let's me get this straight:
- MS publishes their hotfixes with a warning that they may break things and you should only install them if you're having problems;
- Sysadmins are at fault for not ignoring MSs warning and blindly installing all hot-fixes immediately
- If you'd blindly installed all MS hotfixes, you might break earlier hotfixes
-
Service Packs are mostly just rolled-together hotfixes, but they are known to wilfully break things;
- Despite MS warnings to the contrary, Service Packs need regression testing but hot fixes don't.
A hotfix (...) has never (to my knowledge at lest) changed anything.-
The hot fix that would have blocked code red was undone by a later hot fix.
-
The hotfix that would have blocked slammer was at risk of being, itself, slammed by a later hotfix installed in the 'normal' way.
- MS's own servers were broken by the slammer virus.
Just how much knowledge do you have, anyways?OS Software is like love: The best way to make it grow is to give it away.