Re: MicroMonopoly aids Terrorism?

From: kurttrail (dontemailme_at_anywhereintheknownuniverse.org)
Date: 02/04/04 

Date: Tue, 3 Feb 2004 18:32:57 -0500

Charles Otstot wrote:

> "kurttrail" <dontemailme@anywhereintheknownuniverse.org> wrote in
> message news:%23cgFvQd6DHA.3008@TK2MSFTNGP09.phx.gbl...
>> Jupiter Jones [MVP] wrote:
>>
>>> I did not lie.
>>> You on the other hand are taking a giant leap to say "You lied..."
>>> You need to look up the word in a dictionary before you so
>>> carelessly use such a strong negative word since you apparently do
>>> not know the meaning.
>>>
>>> The patch is simple to install.
>>> You do not get much simpler than it is to install.
>>> The hard way is to download the patch, reboot, disable unnecessary
>>> applications then install by double-clicking the icon.
>>> The easy way is to let windows Update take care of it.
>>> For proof the patch is simple to install look at all the successful
>>> installations no one ever heard of.
>>>
>>> Many that did not install it were lazy.
>>> The vulnerability as well as the fix were available and much
>>> discussed weeks before Blaster came out.
>>> Most security experts were not surprised and most were adequately
>>> prepared.
>>>
>>
>> http://www.sqlmag.com/Articles/Index.cfm?ArticleID=38537
>>
> <SNIP TO END>
> kurttrail,
>
> It appears your reference to sqlmag is to support the supposition
> that the SQL patch (MS02-061) which covered the Slammer vulnerability
> was difficult to install (and by extension that the Blaster patch was
> also difficult to install).
> If so, I'd like to point out a couple of points from the article.
>
> 1) Installation difficulty.
> It would (IMO) be reasonable expect a SQL DBA to have the
> requisite knowledge to either perform the manual steps
> required (and documented as required) to intsall the patch or
> to develop his/her own automated installation (e.g.
> through a batch file).
> For those who were unable or unwilling to do so, Microsoft
> did, as noted in the article, re-release the patch with an
> automated installation immediately upon the release of
> Slammer. Microsoft also changed patch development for SQL
> Server to move away from manual installation patches to
> automated installation patches.
>
> 2) Cited reasons for not installing
> Installation difficulty was only one reason cited for some
> people not installing the patch. Indeed, the tone of the
> article indicated (to me at least) that this was a no more
> important (and perhaps a less important) reason than the
> two reasons initially cited in the article:
> a) Lack of ISV support.
> As indicated in the article, many ISV's only
> support Service Pack releases and do not support interim fixes
> such as security updates. In the article,
> Microsoft indicates they are addressing this issue with ISV's.
>
> b) Downtime concerns because SQL Server SP's and patches
> have no rollback feature.
> This is an ongoing concern and is certainly a
> valid issue for many organizations, particularly those without
> the funds to maintain test systems to provide
> assurance that patches and service packs will not bring down
> their (SQL) applications. Microsoft states that
> they are addressing the issue short-term for security fixes and
> are working long-term to provide the same
> capabilities to Service Packs.
>
> Although it is not mentioned in the article, one reason I kept
> running into was people stating that MSDE was in so many applications
> and that admins were unaware of it's existence in their applications;
> hence those instances went unpatched.
> From a system administration viewpoint, I find this as simply
> unacceptable for an explanation. With very few exceptions, MSDE only
> installs by default on Server and Developer applications. "End-User"
> applications that offer MSDE (including MS Office) require a
> conscious decision to install the component. Given this, virtually
> anyone with MSDE installed *should* have known it was installed.
> Systems Administrators and developers certainly have a responsibility
> to know every application installed on the systems for which they
> have responsibility, leading to the conclusion that not knowing that
> MSDE was installed is a failure on the administrator's part *not* MS
> (or any other vendor). Any admins who were caught by this reason were
> certainly (IMO) negligent.
>
> All of these factors lead me to conclude that installing the MS02-061
> SQL Patch was and continues to be a task that should have been within
> the grasp of virtually any SQL administrator and installation
> difficulty should be at most a minor contributing factor to why
> systems went unpatched.
>
> Charlie

Not if the patch makes it so you can't use SQL server. And how many times
previous to slammer did those admins get burned by a patch that screwed
something else up? I have a small 8 computer network at work, and I just
don't download MS patches, just because MS put one out. I download in on 1
machine first, and make sure the cure isn't worse than the disease. I'm no
computer genius, but once you've been burned once, you get gun-shy. Plus
many IT departments were running understaffed that they just had a hard
enough time just keeping their sh*t running as it was, let alone adding time
to test the multitudes of MS patches that get released.

And even MS got slammed. And MS can afford the best minds on the planet to
work for them!

http://www.cnn.com/2003/TECH/biztech/01/28/microsoft.worm.ap/

Yes, some just didn't install it for many stupid reasons, and there were
other that didn't for good reason, but the problem is MS releasing their
next gen software before it's ready for prime time.

And this is all in the corporate realm, now bring this down to the Joe
Schmoes, looking to surf the web and not much else. MS's monopoly swiss
cheese is just too difficult for them to keep up-to-date. "Windows Update?
What's that?" Obviously no software is perfect, but if MS was a car, who
want a car that's being recalled every month, and you'd have to fix
yourself. MS needs to be forced to put out their patches on CDs too, and
have them freely distributed any place where computers and software are
sold, kinda like AOL CDs, as long as they have at least a majority of
desktops in the world using MS's OSs.

MS software, unsafe at any speed. Soon we will be seeing the Mother of
Computer Nasties, it just a matter of time. And MS and their supporters
will try blame everybody but MS, but it will be MS's negligence of putting
out software that inherently defective & MS's monopoly position on the
desktop that will the delivery agent for it. When you look at all the
nasties that have slowed down the net in recent years, the one common
denominator is MS swiss cheese. 

-- 
Peace!
Kurt
Self-anointed Moderator
microscum.pubic.windowsexp.gonorrhea
http://microscum.com
"Trustworthy Computing" is only another example of an Oxymoron!
"Produkt-Aktivierung macht frei!"

Relevant Pages

  • Re: !! FIX !! 0x8024400D 8024400D Microsoft Update Errors
    ... I have been addressed to this thread by the italian support of MS ... I can't install the SP3 patch because of the error code you ... Both are symptoms of permissions problems with your file system. ...
    (microsoft.public.windowsupdate)
  • RE: Microsoft Security Advisory MS 03-007 - Problems
    ... We are currently researching a very specific issue with the patch. ... My first install on a freslhly built W2K ... How a Hacker Uses SQL Injection to Steal Your SQL Data! ... box giving hackers complete access to all your backend systems! ...
    (Focus-Microsoft)
  • RE: Installing SQL 2000 onto Server with SQL 2005
    ... I understand that you are not able to install SQL 2000 on a SQL 2005 ... You recieved general network error when SQL is runinng ... Microsoft Online Community Support ...
    (microsoft.public.sqlserver.setup)
  • Re: SBS2008 Premium question
    ... SQL on SBS08 is 'not supported'. ... but puts the system into a state MS do not support. ... The good news is that the 2nd server license can be used as a minimal ... install of Windows+Hyper-V (it does not have to be Core only but does need ...
    (microsoft.public.windows.server.sbs)
  • Re: Thank you for this informal D2005 fix
    ... it's wonderful to be at the receiving end of the 'spirit of Delphi'. ... > effort it takes to release a patch or an update. ... > implications and ramifications are for the support team. ... >> How hard can it be to modify an install script to inclluse the new ...
    (borland.public.delphi.non-technical)