Re: MicroMonopoly aids Terrorism?

From: kurttrail (dontemailme_at_anywhereintheknownuniverse.net)
Date: 02/06/04


Date: Fri, 6 Feb 2004 10:13:41 -0500

Charles Otstot wrote:

> "kurttrail" <dontemailme@anywhereintheknownuniverse.org> wrote in
> message news:eoGML4q6DHA.3360@tk2msftngp13.phx.gbl...
>> 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
>
> <kurt's reply (for clarity)
>> 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.
>>
> I don't think you'll find any disagreement here that patching for the
> sake of patching is a bad idea (regardless of OS or application). You
> certainly won't get any disagreement that many IT departments are
> undermanned and that patching (and otherwise hardening) has often
> been a back-burner item.
> Where you will get disagreement is over the breadth of severe (e.g.
> rendering the server unusable) or even minor problems from experienced
> admins and engineers. Those who pay attention and test properly are
> really the majority and those folks tend to have a very low incidence
> of problems with MS' or any other vendors' patches/Service Packs. I
> can think of only one patch that I have ever installed (since 1987)
> on a Microsoft system that killed a production box. That particular
> issue was corrected by a vendor update to an array controller driver
> that was out prior to the patch (i.e. *my* error, not MS').
> This is NOT to say that MS has not had patches that caused problems;
> it does mean that I (and most others here) test and review patches in
> accordance with good practices to minimize the risks associated with
> patching. This is something one should do regardless of the
> environment.
>
>> 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/
>
> No one is disputing that MS was hit by Slammer. The question is
> whether the level of difficulty in applying the patch was a major
> factor in why people didn't install it. The article you cite here
> indicates that MS systems that were affected were under the care of
> admins who "didn't get around to it" (from the article). There is no
> indication that MS' admins considered the patch too difficult to
> install. Lazy admins at MS are just as negligent as those for any
> orgainzation. However, this does not invalidate the supposition that
> this patch posed no special installation problems.
>
>>
>> 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.
>
> I won't disagree that MS has released products before they were
> completely tested and *truly* ready for release. However, this is
> *not* a Microsoft problem alone. Market pressures long ago led to
> many (if not most) vendors releasing products before they were truly
> ready for market. This includes hardware and software. Think back to
> VESA-bus technolgoy and early PCI technology. VESA was released as an
> interim architecture to bridge the gap between ISA and PCI in the
> latter days of the 486 environment. At best, VESA boxes were often
> kludgy and VESA-enabled boxes tended to be low-end boxes that
> required a boost (for video, since this was virtually all VESA was
> ever used for) to compete with the perfomrnace of higher-end ISA
> boxes. Early PCI boxes were often subject to the very interrupt
> conflicts that the technology was intended to elminate.
>
>>
>> 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.
>
> I will certainly agree that the "Joe Schmoes" of the world need a
> better mechanism for keeping their systems safe. Unfortunately,
> tackling this issue opens a Pandora's box of issues that will be
> difficult for Microsoft (or any vendor) to fully adress. I would not
> use the "recall" analogy, I would consider patching of any system
> more of a maintenance scenario (just like checking your brakes every
> 30,000 miles and replacing when necessary). Philisophically, I have
> an issue with singling Microsoft out to *force* them to put their
> patches on freely distributed CD's (regardless of their market
> position). From a practical perspective, I think this would be of
> little value. The "Joe Schmoes" would tend to look at the updated
> CD's and think "Oh, a Microsoft CD...wait, I already got one of
> those. Soon enough, they would be treated just like AOL CD's, people
> would get the CD in the mail and make a fish scuplture on their wall
> with them.
>
>> MS software, unsafe at any speed.
> Really depends on who is using it, just like any other
>
> Soon we will be seeing the Mother of
>> Computer Nasties, it just a matter of time.
> Very possible. We just have to make certain we're as prepared as
> possible (with Windows or any other OS).
>
> 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.
> No, the one common denominator is that the authors of those nasties
> didn't have the moral fiber to realize that they had no business
> messing with other people's property. Design (good or bad),
> administrative negligence, ignorance or just plain wanting to have an
> open system cannot be blamed for the actions of individuals. We alone
> are responsible for our actions, this includes malware authors.
>
> Charlie
>

I can basically agree with most of what you're saying. When it comes to
large networks, I am talking way over my head. I can only go by what I
read, and from what I read the original slammer patch made SQL server
not work right for some that did test it because of some conflict with
their ISVs, so they ended up not implementing the patch. I'll
definitely bow to your greater knowledge on the subject ot SQL server &
Slammer.

BUT, when it comes to the average joes, there will always be people that
try to screw around with them, however, it is MS monopoly OS that is
being exploited by these virus/worm reprobates time and again. And this
has been my main point. With true competition in the Desktop PC OS
market, there would be less of a pool of people that would be affected
by any one given computer nasty. Just as in the corporate world where
Slammer only could infect un-patched SQL server, but those using other
non-MS database server software were unaffected by Slammer, the average
consumer would be less venerable to computer nasties if there was some
legitimate choice in the Desktop OS market. The corporate world can
afford the best & brightest people to help safeguard their computer
system, and for one reason or another they still get bit, but the
average joe has only their own limited intellectual resources to depend
on, and all of the joes are potential targets by any one given computer
nasty, because they all are trapped on one target, that of MS's monopoly
Desktop OS.

There will always be some bad eggs trying to mess up the computer world
with viruses, worms, and such, by exploiting vulnerabilities in
software,
but MS's monopolistic practices in the consumer Desktop OS market only
makes it easier for these a**holes to screw up the computer world for us
average joes. Distributing these threats over multiple desktop OS
platforms would be a much better position to be in, to help protect the
general public from these computer terrorists.

Sorry it took me so long to respond to you but I was having my own
database-related problems yesterday. Thanks for your intelligent
responses in this thread, I have definitely benefited from your wisdom.

-- 
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: [Full-Disclosure] DCOM RPC exploit (dcom.c)
    ... > With regards to slammer, again it was successful due to, as you put it ... > a VPN-ed laptop the patch has been released for folk, ... > patches are tested and integrated as soon as available. ... >> boxes down for days after the worm hits. ...
    (Full-Disclosure)
  • Re: [fw-wiz] worm + VPN + firewall
    ... > I have worked with a client that started getting RPC scans from their VPN ... Even many that tried to patch got slammed here, ... Slammer showed that a patched ... or that even other patches might put the system back into high risk. ...
    (Firewall-Wizards)
  • Re: SLAMMER WORM for SQLSERVER2K
    ... This will bring your SQL server up to date with patches. ... links on this page for more info about Slammer. ... > Checked by AVG anti-virus system. ...
    (microsoft.public.dotnet.security)
  • Re: SQL thinks its Slammer
    ... I know of no anti-slammer heuristics built into SQL Server. ... protection was a relatively simple patch to address the buffer overrun ... 2000 SP4 has the slammer fix, and if multiple queries are used the SQL ...
    (microsoft.public.sqlserver.security)
  • 64bit patch question
    ... I know 64bit SQL Server has sp3a rolled into the install and I know that ... there is a 64bit MS03-031 patch. ... Do the rest of the patches work for 64bit or is MS03-031 ... the last and only one beyond the install? ...
    (microsoft.public.sqlserver.server)