response 25 of 62:

Aug 3 05:23 UTC 2003

re#24:  Thats not a particularly helpful suggestion.  There are many
orgs where even if the individual wanted to replace M$ OS entirely the
org rules specify approved OS and that is M$.  And further, 'virtual' M$
OS would in this case be equally vulnerable to the exploit (I gather you
have not seen the exploit code) and whats worse, the ISS free tool for
scanning for vulnerable machines won't find it.  (I have personal
knowlege of this)

Word.  Folk, install the update before its too late.

response 27 of 62:

Aug 4 04:44 UTC 2003

re#26: Just like everybody else that bothered to look I had the dcom.c
to the initial exploit and did exactly as you describe.  I don't have
the source *yet* to the worm to do the same.  My point was that your
virtual windows scenario in fact prevented the ISS scanner from
functioning and things like ISS etc are what most orgs have to rely on.
Thus your suggestion to eliminate M$ OS may in fact be technically
correct, but meaningless as in the real world the environment in user
space is M$ OS and unfortunately to an increasing extent in server space
as well.

Install the Update before it is Too Late.

response 29 of 62:

Aug 5 05:45 UTC 2003

Look, there is no debate that M$ OS's suck.  Thats irrelevent.  Its what
you have to use on a PC.

Install the Update before it is Too Late.

response 31 of 62:

Aug 5 11:27 UTC 2003

I use Linux or BSD on most of my PC's. I don't see where you "have" to use
MS unless your boss forces you to.

response 33 of 62:

Aug 5 13:22 UTC 2003

yeah, I have that on the one Windows computer I use at work as well.
Fortunately my admins are Unix buffs, so they usually don't complain.

response 35 of 62:

Aug 6 06:02 UTC 2003

re#34: The vulnerability scanner attempts to detect the presence of the
vulnerability without subverting the machine and relies among other
things on the ability to detect the tcp stack implementation.  By
definintion, in order to emulate/interoperate the emulated Wintel would
be equally vulnerable to the DCOM/RPC exploit(s).  Thus the emulated and
vulnerable machine was even more of the threat since it was hidden.

From a pure tech play the emulated M$OS environment with an ids running
in the native OS is clearly superior.  Unfortunately its more expensive
and the emulation runs slower than the cheaper native system so its not
likely to be implemented.

---

Depending on the size of the organization there are simple support
issues with allowing anything other than a "standard" build of an OS to
run.  It is a management issue not a technical one.  And often there a
requirements such that an independent auditor be able to sign off on an
org's compliance with legal standards that they would obviously not be
willing to do so if the org's users all had "pink ones" - hand built
hardware/software systems.

From a technical perspective the geek users get this "approved build"
and notice many "flaws" - not realizing for example that downlevel code
in some area may be to allow a specific legacy application to function
that only a small number of critical users even know about and so
naturally "fixes" it, goes on his/her merry way, and lies to support if
there is ever an issue and has a generally poor opinion of the process
not having all the technical details.

An observation that even Russ probably hasn't noticed.  Often the
process of "installing an approved load" of an OS involves literally
cloning a clone of an approved and working "seed" machine rather than an
actual OS load of a distribution by its nature resulting in a fragmented
filesystem that degrades from there.  I have personally seen as high as
50% fragmentation and so often the first thing one can do to improve
things is to defragment your drive (this is Wintel specific advice
obviously).  There is a slight possibility it may break things but these
days not as likely - things tend to work better not worse if they work
faster.  Again, this tends to not exactly give the geekly a high opinion
of the process.  (Obviously the solution is to defragment the seed
machine before its "load" is approved and cloned - but the geeks
invariably are not inclined to share that information with those
building the approved machines.)

Install the Update before its Too Late.

response 37 of 62:

Aug 13 07:18 UTC 2003

and mysteriously broken stuff from time to time - been there, got the
hat and the t-shirt.  Consider for a moment that you are trusting the
"automatic update" function to the same folk that brought you the shitty
OS in the first place.  Like Duh.  How stupid is that?

response 39 of 62:

Aug 13 13:04 UTC 2003

I've actually only had one update that broke anything.  (Q328310 -- it
causes random BSODs on some NT 4.0 Workstation systems.)  Anyway, if
you'd rather get hit by a worm, be my guest. ;>

response 41 of 62:

Aug 13 14:52 UTC 2003

(obligatory Linux zealot gloating)

response 43 of 62:

Aug 13 16:28 UTC 2003

Nor even us Mac weenies. :)

response 45 of 62:

Aug 13 18:35 UTC 2003

<prepares for flame war born of endless PC/Mac conversions problems on
work demanded by boss>

response 47 of 62:

Aug 13 18:53 UTC 2003

I dunno, mary; right now, the micros conference is kinda dull.  We could start
a few items and see. :)

response 49 of 62:

Aug 13 21:42 UTC 2003

In this case, it wouldn't have.  The current worm doesn't spread through
email, it scans for vulnerable machines and infects them directly.